<div dir="ltr">I'll do some more tonight, so hang on!  I'll probably concentrate on looking at the "gap" first.<div><br></div><div>My initial impression of the gap was that it looked like a big import of a working copy.  There were a lot of temporary files, editor backup files, etc. brought in at that point (which I removed in the git import I thought, but your email makes me think I missed some -- will look).  I wonder if this might have been after a "merge" with the ARGE data somehow?  Or maybe a big commit from the on-expo machine or similar?</div><div><br></div><div><div>Probably easiest for you to do things on separate branches for the moment, and I will update the master accordingly.</div><div><br></div><div>In fact if you want to look at something else, there are some problems later on, where some ARGE data was brought in containing multiple years' surveys in the same hg commits.  I fear this may be quite extensive.  Unfortunately I've forgotten the revision that I saw this at now, but I think it was some 2014 data present in a later commit including other (later) updates too.</div><div><br></div><div>Disentangling (or even maintaining this going forward) all seems like a lot of work and I'm starting to wonder if it's worth it.  To keep the "yearly checkpoint" scheme working, we need to make sure that changesets don't touch multiple years at once, and that any subsequent change to a previous year gets rebased to a point between the appropriate two yearly tags.  I fear this is going to cause a lot of rebasing and changing of revision numbers which may cause a nuisance and potentially trouble -- it will also likely complicate any proposals for non-nerd-friendly workflows.  What tangible benefits do we actually get from having this property?</div><div><br></div><div>Mark</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 3 May 2020 at 17:00, Wookey <<a href="mailto:wookey@wookware.org">wookey@wookware.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2020-05-03 04:49 +0100, Wookey wrote:<br>
<br>
> post-2001 fixed by:<br>
> looking for 2000-aa-01 instead of 2000-AA-01<br>
<br>
OK. doing it this way conflicts later so change to re-case the file<br>
instead which is better (I only did it the first way as I thought that<br>
would avoid conflicts).<br>
<br>
> So I've pushed a '2001' branch (to avoid clashing with the tag 'post-2001' - my git-fu doesn;t run to distinguishing between branch refs and tag refs with the same name) with a working version, which should probably be folded back in at the post-2001 tag.<br>
<br>
Rebasing 2002 onto that 2001 makes it work too.<br>
<br>
> I wonder what else is missing... Worth checking survey dates I guess<br>
> to see what should be promoted forwards in the dataset.<br>
<br>
There are no files dated 2001 that appear between them. So that looks good.<br>
<br>
Trying same for 2003 (rebase on top of fixed 2002) gets to the tricky<br>
bit. Most conflicts are the stuff fixed above already for 2001 and are<br>
auto-merged. Good. But the 'Gap' checkin does al sorts of stuff.<br>
<br>
This looks like a combination of<br>
1) big rework so southern end (078, 041, 115 get 80s CUCC<br>
data removed and new ARGE stuff used. Fine.<br>
2) leading zeros on cave dirs dropped.<br>
<br>
However there seems to be a revision to older versions of files:<br>
In 115 and 41 it's reverting comment-> *title and date -> *date stuff and<br>
removing umlauts which it shouldn't be. (maybe that really did happen, but it shouldn't have).<br>
<br>
Also various other things:<br>
caves/115/115.log gets in - shouldn't be there.<br>
files like caves/40/arge/.nfs* and caves/40/arge/.*.svx.swp and caves/40/arge/__svxtmp.svx appear<br>
lots of trailing spaces and tabs in added 144 files. yuk.<br>
removes 40area.svx, .gitignore adds cvsignore<br>
<br>
It possible (likely even) that all this reversion to older files gets<br>
dealt with later. Needs some investigation to work out what the right<br>
set of changes is that will work, accurately represent the year and<br>
not conflict with lots of stuff later.<br>
<br>
Sending this now as you said you were going to do some more. I'll look<br>
some more too to try and work out what's what, but not necessarily tonight if you are.<br>
<br>
This 2002(CVS) to 2003(SVN) jump is the main tricky bit I think, until whatever happens after 2015.<br>
<br>
<br>
Wookey<br>
-- <br>
Principal hats:  Linaro, Debian, Wookware, ARM<br>
<a href="http://wookware.org/" rel="noreferrer" target="_blank">http://wookware.org/</a><br>
_______________________________________________<br>
Expo-tech mailing list<br>
<a href="mailto:Expo-tech@lists.wookware.org" target="_blank">Expo-tech@lists.wookware.org</a><br>
<a href="https://lists.wookware.org/cgi-bin/mailman/listinfo/expo-tech" rel="noreferrer" target="_blank">https://lists.wookware.org/cgi-bin/mailman/listinfo/expo-tech</a><br>
</blockquote></div>