Hello, my name is Thomas and I am new to darcs. I like its concept and therefore I am currently evaluating it for some small project.
A few days ago I have written down some mental notes about darcs so that I can remember them later, but in the light of the discussion about the "dangerous" unpull command I thought I share them with you. As I said, I am new to darcs' concepts, so please tell me (personally) if the ideas are complete nonsense. David Roundy wrote: > On Mon, Aug 01, 2005 at 06:48:37PM +0900, Stephen J. Turnbull wrote: > >>>>>>>"Erik" == Erik Schnetter <[EMAIL PROTECTED]> writes: >> >>Erik> We could introduce a directory /deleted-patches and put a >>Erik> copy of the patch there. This way it could be resurrected >>Erik> with "darcs undelete". >> >>Don't we have plenty of options for keeping the patch in the >>repository but not using it in the current workspace? > > > Actually, this isn't such a bad idea. We could keep a patch bundle > around. I think I'd rather avoid darcs undelete, though, if at all > possible. We've just got too many un-commands already. On the other hand, > if done right the uncommand naming scheme can be intuitive. Problem: The unpull command is bad. It deletes patches which are thought to be safe. A version control system must not do this! Therefore I propose the following solution: For each working directory keep a set (in a mathematical sense) of which patches must be applied to an empty repository so that the pristine tree can be reconstructed. Not all patches from the _darcs/patches directory need to be in that file. Record just adds the patch in question to the set, unpull removes it from the set. Since patches are only added to _darcs/patches and never removed (only the set file is changed) patches cannot get lost. On "pull" the _darcs/patches directory is synchronized with the remote repo, and eventually the patches are added to the set. Ideally (i. e. all repositories are up-to-date) all downstream repositories have all the files in _darcs/patches that upstream also has. The set file however is only equal in case the two repositories belong to the same development branch. Justification: Since a patch's inverse can always be computed, switching from one development branch to another means calculating the set difference between the current set and the destination set and adding and removing (adding the patch's inverse) the patches as required. The computation time required is proportional to the difference in the branches thus very fast most of time. Bonus: If having more than one repository on a disk the _darcs/patches directory can be symlinked as a whole, therefore saving disk space. Therefore the cost of branching is significantly reduced. If this idea is unclear or not feasible please tell me. Thomas -- Use other side for additional listings. _______________________________________________ darcs-users mailing list [email protected] http://www.abridgegame.org/mailman/listinfo/darcs-users
