Ketil Malde <[EMAIL PROTECTED]> wrote: > Ben Franksen <[EMAIL PROTECTED]> 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 _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
