On Mon, Jul 28, 2008 at 11:15:02PM +0000, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
g. Anyone having local branches which are based off of commits in the old git repository will have to rebase those
How do you go about that? Manually rebasing every branch
yes.
Even if it's simple to rebase, I think it'd be best to avoid steps f-h as much as possible.
absolutely.
If nothing else, it's inconvenient (and confusing) to have to keep several old repositories around
you don't need several repositories, you can keep them all in one repo. but thaty doesn't ease the confusion, especially once you get multiple such branches.
I don't agree very much with the intended collaboration model, though.
there is no intended collaboration model, you can choose any model you like.
Apparently there should be no central repository, only developers that pulls each other's changes in some ad-hoc way.
that is just one way to do it, and this model is most often explained as it is a new model that dcvs makes possible, in other words, if you want this model, then dcvs is the only way, but that doesn't mean that other models are less well supported or inferior or anything.
git can work just fine with a shared repository too. I wouldn't like to see the plethora of branches and merges on the server, though.
agreed.
A nice linear sequence of commits on each version branch keeps things simple. We've been working that way for years now and I haven't seen any real reason to change that. But that shouldn't be a big problem to accomplish just by dictating policy, I guess.
i think for us a mixed model makes the most sense. people with write access push into the core branches, but other potential contributers can still be pulled from by a core developer and then pushed from there.
Zino has good points that svn fits better on the server: It's more mature,
more mature in what sense? if everyone uses git on the client side then the maturity of svn on the server does not muy anything because you still have to deal with git. it only adds hassle which wouldn't exist otherwise.
it's closer to cvs so that the server tools around it don't need much change,
the largest change should be in the fact that the rcs files are not accessible anymore but have to be replaced with calls to the svn module. at the same time calls to git can be added.
and it's afterall built with that sharing model in mind.
it has been built with a "this is all we know, so this is all you get" mindset. git is being built with a "there are many ways to do it, and we want to support all of them" mindset.
Maybe a good way to accomplish both ends is to use the bidirectional git-svn bridge? Afaict it's made for the case when the primary repo is in svn. It advices against doing git-style heavily branched development, which is good on the server side (see above). And using svn for storage allows properties, which git lacks. I will play around a bit with git-svn.
the only thing that would accomplish is to enforce limitations that svn has. with a small group as pike devs are, i think such enforcement is not necesary. policy should be enough.
git-svn is the most featureful dcvs-svn bridge i came accross (only bzr might be a bit better, but it is less mature), but it has it's limitations. the largest one is lack of merge tracking (you can't merge into a branch that is to be commited to svn, even though it could be made possible (the reason for that is actually because git can't rebase merges (yet)), another is that it is limited to a certain branch layout (not a problem for the pike repo)
greetings, martin.