Hi Stephen, I hope this three-month-late reply isn't a problem. I had made a note to myself to just "write down uses for remote branches" from your mail, but upon re-reading I realised I did not understood your mail well enough. So I was hoping for some clarifications.
Eric wrote (around 3 Jan): >> 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 should mention that having used Git (and github) some more I have warmed somewhat to the idea of remote branches. That said, I'm *still* nervous about not being able to do it in a way that keeps Darcs simple and friendly [at least for the workflows it currently supports]. That nervousness was why I was hoping we could get away with just local branches. Now I suppose that wouldn't actually be making things that much simpler and that if we were going to do branching at all, we might as well just go all the way. Hopefully we *can* pull this off if we're sufficiently thoughtful about it. On Sun, Jan 03, 2010 at 01:47:31 +0900, Stephen J. Turnbull wrote: > 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? For more context, I later replied saying that the only thing I was concerned about was opening up a can of UI worms, that adding all the necessary concepts/distinctions/operations to support branches may make Darcs more difficult to understand and use. > 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. In the case of local branches, I think I'd agree that it's just a question of pushing/pulling patches. For remote branches, don't we run into the usual advice of not performing git rebase (or darcs obliterate, or darcs amend) on already-published work? > 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.) About fast-forwards, reading http://marklodato.github.com/visual-git-guide/#merge gives me the impression that a fast-forwards in Darcs is just the case of pulling patches where "our" history is just a prefix of "their" history us p1 p2 p3 them p1 p2 p3 t4 t5 t6 In that case, no patch commutation happens; we just grab and apply. On the other hand, our working directory changes (on top of p3) would have to commuted past the new patches. A less simple case would when we have changes of our own us p1 p2 p3 u4 them p1 p2 p3 t4 t5 t6 In which case we would do some patch inverse and commutation work so that we could pull t4..t6 on top of { p1, p2, p3, u4 } instead of just { p1, p2, p3 }. This would result in a repository that looks like this us+them p1 p2 p3 u4 t4' t5' t6' where t4'..t6' are the result of commuting inverse(u4) past t4..t6 [repeating] > [B]y default, remote operations are only permitted if > they are fast forwards. ... > 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'm a bit confused here. What do fast-forwards have to do with the number of branches? In "remote operations are only permitted if they are fast forwards", I understood something that you can only push patches on to repositories whose history is a prefix of ours (like above, just flipped). Whereas in the second sentence, I think you're talking about a UI scheme to discourage branch proliferation. > 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. How would this be different from the current Darcs equivalent of just pulling from a remote repository (as opposed to a branch within that repository)? Does it matter what you meant by bootstrapping a project? I thought you were speaking informally saying something like "do some arbitrary operation foo [configure, make] to get the working dir to some arbitrary useful state [can run make test]" > > > 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. Thanks for all the advice, -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9
signature.asc
Description: Digital signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
