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

[Michael Conrad]

Ketil Malde <ketil.malde at bccs.uib.no> wrote:
> Ben Franksen <ben.franksen at online.de> writes:
>
>> I am not exactly sure what you mean with 'partial repositories'. Are you
>> thinking about e.g. CVS where you can work with only a subdirectory of  
>> the
>> whole repository?
>
> Yes, exactly.
>
>> If I understand you correctly, you think this could be
>> done (with the ghost proposal) by 'darcs remove'ing stuff that you don't
>> want to have lying around. Maybe, but why would you want to do this?

> If they were all in a single repo, I would be able to produce combined
> patches, but somebody who just wanted to use the library would have to
> pull the whole thing.

Well, I see one main problem in this idea, but it might be fixable with a  
modification to darcs' patch format...

(Anyone feel free to correct me if I'm wrong, its been a while since I  
looked at this)

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.

(the first case I was going to describe was if people try using the same  
names of files as ghost files.  but really, it can all be worked around by  
renaming ghosts.  so not a compelling problem)

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 ]

Suppose Person1 doesn't have Blah.txt, and darcs just ignores this in all  
relevant patches.  BUT! suppose Person2 and Person3 don't have the same  
Blah.txt.  They each created the file independantly and are not aware of  
eachother's patches yet.  Now suppose person1 pulls the patch from person2  
that created person2's Blah.txt.  Darcs takes the patch to its earliest  
dependancy, and commutes it downward.  In this case, it commutes all the  
way form the beginning.  So darcs commutes with Patch1, then commutes with  
Patch 16, and fails.  or worse, it could happen to succeed!  You either  
end up with a commutation failure, or a corrupt file.


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

Now imagine the same scenario: we receive a new patch which will become  
Patch 26, from Person 2.  We commute with Patch1, and recognize that this  
new file is the same one mentioned in Patch 1, so we alter the file.  We  
get to Patch 16, and ignore it, because they aren't the same file. Patch  
17, we alter the file again, because they are the same.  Onward to 25, and  
we now have the correctly modified BLAH.txt from person2, which still  
ignoreing person3's file of the same name.

Actually, person2 isn't using the same name as person3 anymore... and it  
might be possible to pull in person3's Blah.txt without conflicting with  
anything...  Perhaps if we have these unique IDs to play with, we could  
resolve name conflicts just by moving one of the files to a new name, and  
then forget that the conflict happened (rather than smashing the patch  
fragments together in a wad of glue and slowing down all activity that  
commutes accross it).


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.  If there was a patch in Person2's repo that  
changed Blah.txt between the patch 1 and patch 16, you can't guarantee  
correct contents of Blah.txt without seeing that patch.  That patch should  
be mentioned as a dependancy in Patch 16 though... so maybe BLAH.txt  
continues to remain invisible until you get those relevant patches from  
Person2 (and patches those depend on, and so on).  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?

Eh, someone else's turn to think on this.

-Mike