[darcs-users] making add/remove file commute with content change

Ketil Malde ketil.malde at bccs.uib.no
Thu Nov 29 09:36:53 UTC 2007


"Michael Conrad" <silverdirk at silverdirk.com> writes:

> Every file in darcs has a unique identity when it is created: the patch it  
> came from and what its name was in that patch.  The file maintains a  
> unique identity as it moves around, because no 2 files ever have the same  
> name, and darcs can commute any changes to that file (or its name) back  
> and forth to different times in history.  So basically, darcs uses a  
> file's current name as a unique identifier within the current repo state.

If I understand you correctly, this would have to change.  Darcs would
need patches to refer to files by their unique identity.  Identities
that change seems like a ...not so good principle.

> Problem: If you have patches that alter files that darcs knows nothing  
> about, and darcs ignores these patch-pieces, darcs breaks. (I think).
> Say these are the patches in person1's _darcs/inventory
>    Patch 1, from Person2 [ stuff, and modify Blah.txt ]
>    Patch 2-15 [ nothing relevant ]
>    Patch 16, from Person3 [ stuff, and modify Blah.txt ]
>    Patch 17, from Person2 [ stuff, and move Blah.txt -> BLAH.txt ]
>    Patch 18-25 [ nothing relevant ]

So that'd translate to 

   Patch 1 [ stuff, and modify U1 ]
   :
   Patch 16 [ stuff, and modify U2 ]
   Patch 17 [ stuff, and rename U1 from Blah.txt to BLAH.txt ]
   :

That U1 happens to be named Blah.txt in Person2's repository, and U2
has the same name in Person3's repo shouldn't matter.  As long as you
don't try to give two files the same name at the same time.

I'm not sure how renamings would commute if they involve the same
name, but possibly one could just be conservative on this?

> Now suppose that we alter darcs so that the name is simply an attribute of  
> a file, and a file is always referred to by its unique ID.  A move patch  
> fragment would be something like
>    mv UNIQUE_NAME_OF_FILE old/path/and/name new/path/and/name

Yes.

> Actually... there's still a problem with this.  You can't apply a patch  
> that alters a file unless you know that you have all the other patches  
> that have altered the file.  

Uh, can't you cherry-pick patches with darcs?

> I see that as mainly a user interface problem, though.  Maybe having
> ghosts that can be seen with a special darcs command would be a way
> to let users specify which files they want to have darcs go collect
> the dependancies for?

Well - I imagine 'ghost hunks' would only be pulled when they are in
patches that apply to non-ghost ("live"?) files.  So unless you
implement some trickery to decide which dependencies are really
needed, all dependencies would be pulled in, which  I suppose would
include at least file creation, voiding the entire scheme.
:-)

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants


More information about the darcs-users mailing list