Johan Tibell writes: > > I just had a thought on one principle we could adopt that could help > > us preserve this simplicity. Johan: since you're an active user of > > branches, could you comment on the following idea? > > > > Darcs should never implement 'remote' branches.
I'm not Johan, but let me comment anyway. I don't understand who you are trying to save from what here. At the lowest level, you're saying it matters whether the patch I need is currently stored locally or in some other repository. That's clearly a mostly bogus distinction.[1] Copy the patch and be done with it, OK? The next level problem is that if your VCS supports colocated branches, you might commit to the "wrong" branch because you forgot which one you're in. Fixing this is just a rebase (and maybe splitting the first patch). Well, hey, isn't Darcs the world's best tool for rebasing, and no slouch at splitting up patches? And note that this can surely happen without *remote* branches. Finally, when pushing or pulling you could indeed make a big mess by increasing the number of branches and silently switching to the "wrong" one. That's a real problem for Darcs, I think, just as for git, but git's solution (and Mercurial's, and Bazaar's) should be applicable here: by default, remote operations are only permitted if they are fast forwards. (I'm not sure exactly what "fast forward" means in the context of Darcs, but to the extent that it's somewhat fuzzy that's precisely because Darcs knows how to handle most situations, I think.) In other words, Darcs is only allowed to increase the number of branches in the target repo if the user specifies the branch to add *and* some kind of "new branch" option. I can think of one use case where pulling a remote branch would be very useful. That is the case where bootstrapping your project is very expensive. The workflow here is to create a repository in one of the usual ways, and bootstrap it. Now, if you want to test someone's changes, instead of cloning their branch (moderately to very expensive in a big tree) and bootstrapping (very expensive), you simply pull the delta to their branch into your "build&test" working tree and remake the changed files. > > Branches should be strictly a personal affair, something a hacker would > > use to work on multiple features at the same time, or a maintainer to > > keep track of a bunch different patch sets; but NOT for a project that > > wants to publish multiple branches (they'd have to do it the old > > fashioned way). I use git to synchronize multibranch repositories across several hosts all the time, and I just don't see a problem, as long as I don't rebase. In fact, in a couple of cases I've had several wildly divergent versions, and I just pull the branches into one repo from wherever they might be, and mix and match with cherry-picks and merges until I've achieved a set of sane up-to-date branches. I see no reason at all why Darcs shouldn't be even more efficient for this kind of thing. > >> Aside: I want all my history locally so I don't use lazy. > > > > Even when branching an already local repo? What's there to lose? > > I didn't really use local branches in Darcs but I imagine that --lazy > would be fine that although perhaps subsumed by hard linking. I find > that to be an optimization that the tool (i.e. Darcs) should worry > about. Very true! But coming up with a robust and simple policy is not easy. Eg, git's defaults are now quite efficient, but the record of false starts is easily visible in the list of space-optimizing options to "git clone". Footnotes: [1] I say mostly bogus because Emacs is experiencing a lot of pain in their transition to bzr, and a certain portion of that pain is due simply to the fact that that the Savannah admins took advantage of the flexibility in transports of remote versions that bzr offers to pessimize checkout and clones of branches. _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
