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

AntC anthony_clayden at clear.net.nz
Tue Sep 18 22:22:25 UTC 2012


Stephen J. Turnbull <stephen <at> xemacs.org> writes:

> 
> 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.

Careful here! A move/rename is not the same as a file copy. Tentatively:
- move/rename must retain the file's identity
- file copy creates a new file identity
- but (tentatively) copy retains the identity of the contents (lines)
- so pulling a hunk change to the lines
  applies to both the original file and to the copy
  (providing those lines are still in the files, of course)

(This is tentatvie because I haven't yet figured out how hunk changes are 
going to apply on a hunk-line-id basis rather than a file-id-line-number.)

> 
> 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. ...

Similarly if we rename a file, we also want to change any #include in other 
files that refer to it. Perhaps this means token replaces apply to the file 
system _and_ file contents?



> 
>  > > 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.)
>  > 
> 
> 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 ...

Thanks Steve for the info re bzr. The usefulness of the unique/persistent file 
id is all for the VCS's housekeeping, not for the programmer. (Or at least the 
only use for the programmer is to be able to show that in comparing repos, two 
files with the same dir/name are not really the same, or vice versa that two 
different-named files are really the same.)

AntC





More information about the darcs-users mailing list