Re: [darcs-users] RE: [Haskell-cafe] fptools in darcs now available
Simon Marlow wrote: But what worries me is: if I just want to check out e.g. Haddock, I have to get the entire fptools repo (350M+, wasn't it?). I can build a source distribution with just the bits I want, but I can't get a darcs tree with anything but the whole lot. So, here's two potential solutions: 1. Make it possible to 'darcs get' just part of a tree. Patches that don't touch any files in the live parts of the tree are discarded. (I don't know if this is possible, or how difficult it is). I like this solution, especially now that David says that it is not impossible to do. In general I think it is a good idea to be able to get a part of the tree -- this might be very useful to handle big projects like the linux kernel where many developers just need to touch tiny parts of the repository. However, I think that darcs should never discard patches: all patches are always applied, and record works just as it normally works. The only difference is that the absent part of the tree is treated as an unobservable part of the tree -- patch applications to absent parts of the tree are just void operations as they can not be observed. In this design, a darcs get on a part of the tree is like building a special view on the tree. (As such, the tree should probably still always start from the root -- one would not be able to just get a bunch of leaves) In this setup, I think darcs will still be able to transparently handle patches that touch present and absent parts of the tree, and also moves from absent to present parts etc. In general, this feature might allow darcs to overcome most efficiency problems associated with large repositories. Alas, I do not know how much effort this feature might take (and I do not volunteer to do it), but it does seem a potentially important one. All the best, -- Daan Leijen. 2. Create separate repositories for GHC, Happy, Haddock etc., and duplicate the shared fptools structure in each project. Each time we modify something in the shared part of the tree, we pull the patch into the other trees. (is it possible to cherry-pick from a tree that doesn't have a common ancestor? If not, can we make the repositories appear to have common ancestry?). Cheers, Simon ___ darcs-users mailing list [EMAIL PROTECTED] http://www.abridgegame.org/mailman/listinfo/darcs-users ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [darcs-users] Re: [Haskell-cafe] fptools in darcs now available
On Sun, May 01, 2005 at 08:28:15PM +0200, Sven Panne wrote: Gour wrote: Nice to hear you are considering to move to darcs. Basically I'm very happy with the working model of CVS, and subversion darcs would allow you to locally record intermediate stages of a change, making it easier to revert to the last good state if you screw up or decide something would be better done a different way. You can also unrecord one of the previous intermediate local commits you have made to fix a bug or do it in a better way. Then, when you have finished the changes and are happy with it all, you can either send of the set of smaller changes (which might make the history more understandable) or unrecord them all and rerecord the whole thing (so it looks to the outside world like you just did it all at once, as is the current case). You can also more easily send only some of the changes you have made to the main repo if you also have some unfinished stuff you are working on. You can also do all this while on a plane, without bandwidth at a conference, or whatever. Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [darcs-users] Re: [Haskell-cafe] fptools in darcs now available
Sven Panne ([EMAIL PROTECTED]) wrote: So my question in a nutshell: Why shall we move away from the mainstream when the rest of the world (or most of) is quite happy with CVS or is moving to subversion? I'm not completely against it, but we should have very, very good reasons to do so. Amongst other reasons mentioned by others, I prefer darcs 'cause it does not have database dependence and I heard enough stories of corrupted databases subversion. (the same argument applies to Monotone as well.) Sincerely, Gour Cheers, S. P.S.: Yes, I'm aware of other development models like the one used for the Linux kernel, where CVS/subversion are not appropriate, but is fptools really a similar project? I don't expect hundreds of people working in a very distributed manner on extensions of e.g. a type checker... :-] ___ darcs-users mailing list [EMAIL PROTECTED] http://www.abridgegame.org/mailman/listinfo/darcs-users -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [darcs-users] Re: [Haskell-cafe] fptools in darcs now available
Also, I think it's easier to split a darcs repo than it is to join them. ... 1. Make it possible to 'darcs get' just part of a tree. Patches that don't touch any files in the live parts of the tree are discarded. (I don't know if this is possible, or how difficult it is). That's an interesting question. It's not a darcs feature now, but I also don't know how hard it is. You can currently do something like darcs changes somepath to get a list of patches that touched that file or directory. You can then do darcs pull -ppatchname for each of those patches. Of course, you can write a shell script to do that second step for each patch. I've done things like this many times. This is an example of what you call splitting a repo, I guess. It isn't that hard. Joining a repo is decidedly easier: mkdir newjoinedthing ; cd newjoinedthing ; darcs init ; darcs pull -a $firstrepo ; darcs pull -a $secondrepo. The only tricky part is doppleganger patches. Basically at this point if you get doppleganger patches then you should manually intervene, figure out what the conflict is, manually fix it, and then resume. It's a big problem, because the manual fix probably makes it impossible to use any darcs patches which depend on (at least one of) the conflicting patches. You would, if you got into that kind of a fix, probably have to write a shell script (or a Haskell program, if you like) to run darcs diff -u -p$patchname | ( cd newreconstructedrepo ; patch -p0 ; darcs record --all -m$patchname ) for every patch that depended on the doppleganger patches. However, avoiding doppleganger conflicts is simple: never make any identical change more than once to any darcs repo. For example, suppose you wanted to add a new subdirectory named happy. You could go to one darcs repo and do mkdir happy ; darcs add happy ; darcs record --all -mcreatehappydir. Now you could go to another darcs repo and do mkdir happy ; darcs add happy ; darcs record --all -mcreatehappydir. Whoops! You just created doppleganger patches! If you ever pull from one of those repos into the other, darcs will take something like O(2^n) time where n is the number of patches that depend on the createhappydir patches. The solution is simply that when you want to create a happy dir in the other darcs repo, you cd into that repo and run darcs pull -pcreatehappydir. Now you have a happy dir in both of the repos, and you don't have any doppleganger patches. The same caution applies to adding files, changing files (such as with patch -p0 newfeature.diff), etc. You must do such things only once, in one repo, and then pull the change through darcs into any other repo that wants the change. As long as you avoid doppleganger patches, then you guys are worrying about this too much. Darcs will make it relatively easy for you to do it this way, do it that way, or change your mind halfway through and move everything around again. It isn't like CVS, where you have to agonize about putting everything in the right place and the start and then live with it for years or undergo painful transitions. Regards, Zooko ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [darcs-users] Re: [Haskell-cafe] fptools in darcs now available
On Fri, Apr 29, 2005 at 11:17:07AM -0300, [EMAIL PROTECTED] wrote: The only tricky part is doppleganger patches. Basically at this point if you get doppleganger patches then you should manually intervene, figure out what the conflict is, manually fix it, and then resume. It's a big problem, I don't know if this is what you call a doppleganger patch, but a lot of times when I try this, I have a problem because files with the same name are added at some point in the history of both trees (even if the current versions don't conflict), and this leads to the spinning conflict resolution. Commonly seen with files named Makefile and the like. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
