[Expo-tech] loser git conversion

[Mark Shinwell]

I'll do some more tonight, so hang on!  I'll probably concentrate on
looking at the "gap" first.

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?

Probably easiest for you to do things on separate branches for the moment,
and I will update the master accordingly.

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.

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?

Mark

On Sun, 3 May 2020 at 17:00, Wookey <wookey at wookware.org> wrote:

> On 2020-05-03 04:49 +0100, Wookey wrote:
>
> > post-2001 fixed by:
> > looking for 2000-aa-01 instead of 2000-AA-01
>
> OK. doing it this way conflicts later so change to re-case the file
> instead which is better (I only did it the first way as I thought that
> would avoid conflicts).
>
> > 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.
>
> Rebasing 2002 onto that 2001 makes it work too.
>
> > I wonder what else is missing... Worth checking survey dates I guess
> > to see what should be promoted forwards in the dataset.
>
> There are no files dated 2001 that appear between them. So that looks good.
>
> Trying same for 2003 (rebase on top of fixed 2002) gets to the tricky
> bit. Most conflicts are the stuff fixed above already for 2001 and are
> auto-merged. Good. But the 'Gap' checkin does al sorts of stuff.
>
> This looks like a combination of
> 1) big rework so southern end (078, 041, 115 get 80s CUCC
> data removed and new ARGE stuff used. Fine.
> 2) leading zeros on cave dirs dropped.
>
> However there seems to be a revision to older versions of files:
> In 115 and 41 it's reverting comment-> *title and date -> *date stuff and
> removing umlauts which it shouldn't be. (maybe that really did happen, but
> it shouldn't have).
>
> Also various other things:
> caves/115/115.log gets in - shouldn't be there.
> files like caves/40/arge/.nfs* and caves/40/arge/.*.svx.swp and
> caves/40/arge/__svxtmp.svx appear
> lots of trailing spaces and tabs in added 144 files. yuk.
> removes 40area.svx, .gitignore adds cvsignore
>
> It possible (likely even) that all this reversion to older files gets
> dealt with later. Needs some investigation to work out what the right
> set of changes is that will work, accurately represent the year and
> not conflict with lots of stuff later.
>
> Sending this now as you said you were going to do some more. I'll look
> some more too to try and work out what's what, but not necessarily tonight
> if you are.
>
> This 2002(CVS) to 2003(SVN) jump is the main tricky bit I think, until
> whatever happens after 2015.
>
>
> Wookey
> --
> Principal hats:  Linaro, Debian, Wookware, ARM
> http://wookware.org/
> _______________________________________________
> Expo-tech mailing list
> Expo-tech at lists.wookware.org
> https://lists.wookware.org/cgi-bin/mailman/listinfo/expo-tech
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wookware.org/pipermail/expo-tech/attachments/20200503/61564023/attachment.htm>