[darcs-users] darcs conflicts/dependencies -- is patch theory the place to start?

Stephen J. Turnbull stephen at xemacs.org
Fri Sep 21 03:49:58 UTC 2012


AntC writes:

 > THis is exactly the sort of example I'm trying to work through. So
 > my approach is (trying to) separate out what applies for the
 > container (file) vs the contents (lines).

Well, I think you should try to sort this in conceptual terms first,
most importantly, what are the use cases where the programmer might
care about the difference between a file's container (which might have
different names either sequentially (renames) or concurrently (links)),
and the file's contents?

 > Remember that we get to observe the repo only intermittently (at
 > record points). Also darcs doesn't (currently, I believe) try to
 > compare before/after contents to guess where lines have gone. It's
 > impressive that git does try. I wonder how reliable it is?

Why do you think it's a guess?  git's find-copy/move-harder features
defines content movement by equality of lines as strings; it is 100%
reliable at finding those moves.  The "pickaxe's" reliability depends
on the user's skill with regexes.  In your model, it would be 100%
reliable even if the entire content of the line had been swapped out. ;-)

 > I'm envisaging a move-file command (as per darcs), and a move-lines
 > command, so that the programmer can be explicit about their intent:
 > - are these two completely new files?
 > - or one with continuing identity, one new?
 > - (whether or not one of the files has the same name as before
 >    is an orthogonal issue)
 > - for each file, is this completely new content?
 > - or continuing content (from where)?
 > - or (more likely) a mix of new and continuing?

This is a rather large burden to place on the programmer.  Will they
really bother to learn to do this correctly?

 > The critical issue is determining how to apply patches pulled from
 > other repos where the file splitting hasn't occured (perhaps a
 > bugfix on the pre-refactored code).

Simple.  You apply it to the same lines.  In git, if you've changed
the content of the lines (eg, variable rename) you won't be able to
find them, but you won't be able to apply the patch anyway because git
doesn't know how to commute patches.

In Darcs, your idea of identifying lines separately has merit, because
Darcs does know how to commute patches.  *But* I fail to see how the
file rename issue interacts with this; it seems orthogonal to me.

 > > Again, which one is the original file identity, if the purpose of
 > > the copy is to divide the file into two by deleting a range of
 > > lines from each?
 > 
 > I'd prefer to handle that as a move-lines for one (or both) of the
 > ranges.

Theoretically, yes.  But will users properly discriminate between
those commands?

Steve


More information about the darcs-users mailing list