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

[Stephen J. Turnbull]

Kevin Quick writes:
 > > If the VCS gives each file an 'internal' id that is:
 > > - unique across all repos; and
 > > - persistent wherever the file goes, or however its location/name  
 > > changes.
 > 
 > Although this sounds alluring from the implementation perspective,
 > I worry about the user perspective on something like this,

bzr does this already.  It only uses it to track renames/copies, and
for most users these really aren't that big a deal.  It also can give
confusing results if used improperly.  For example, if starting at
version N you copy file A to B, then delete 5% of A and 95% of B, and
pull a bunch of related functionality into B from various places, you
can get very voluminous (and therefore confusing) diffs of tip
vs. version N.

On the other hand, there are situations where this capability is
important.  For example, apparently in Java if you rename a class you
have to rename the file containing it.  So this is a rather frequent
occurance for Java programmers, it seems.  (Don't trust my
explanation; this all sounds to me like good reason to quit Java, not
a reason to start bzr ;-).

 > > I'm suggesting the file id be the ppid of when it got added, to
 > > help with the book-keeping. (I'm assuming this can also tell us
 > > in which repo the file started life.)
 > 
 > For your purposes wouldn't any guid suffice?  I'm not sure that the
 > source repo is useful.

bzr again does something similar to this.  Its revision ids contain an
"authority" part (ie, the email of the committer).  I've never seen
this be useful (and indeed it was originally introduced in GNU Arch as
a way of ensuring global uniqueness of version IDs).  It was kind of
amusing to be able to track who did what by listing a directory (Arch,
like Darcs, stored version info as patches in a directory), but of
course that amusement was limited to VCS geeks who looked inside the
repository structure.  I never saw it be useful for VCS operations.

Steve