[darcs-users] making add/remove file commute with content change
silverdirk at silverdirk.com
Thu Nov 29 06:53:28 UTC 2007
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
>> 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.
More information about the darcs-users