> > > Besides, the git-svn readonly bridge is a great solution for those who want > to use git >It seems to be a reasonable solution for those individuals who want to use git, but in my experience not for organizations that want to use git, e.g. have a local server with local branches, with many people banging on that while at the same time continuously merging the LLVM mainline in. Perhaps your experience has been different - I have limited experience with git-svn and git-p4, but have found both to be useful only for me working individually. Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110727/a3e2d098/attachment.html>
Mark Lacey <641 at rudkx.com> writes:> Besides, the git-svn readonly bridge is a great solution for those who want to use git > >> It seems to be a reasonable solution for those individuals who want to > use git, but in my experience not for organizations that want to use > git, e.g. have a local server with local branches, with many people > banging on that while at the same time continuously merging the LLVM > mainline in.Exactly. -Dave
On Wed, Jul 27, 2011 at 8:59 PM, Mark Lacey <641 at rudkx.com> wrote:> >> Besides, the git-svn readonly bridge is a great solution for those who >> want to use git >> > > It seems to be a reasonable solution for those individuals who want to use > git, but in my experience not for organizations that want to use git, e.g. > have a local server with local branches, with many people banging on that > while at the same time continuously merging the LLVM mainline in. > > Perhaps your experience has been different - I have limited experience with > git-svn and git-p4, but have found both to be useful only for me working > individually. > > Mark >Have you considered mercurial? I am not as "current" on git wizardry as I am on mercurial, but at I least verified that branched development and rebasing to tip, r-w- works on the mercurial-svn bridge (i.e. you can commit directly to svn via hg and gain all of the benefits of using a dvcs) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110728/094da3cc/attachment.html>
Jason Kim <jasonwkim at google.com> writes:> On Wed, Jul 27, 2011 at 8:59 PM, Mark Lacey <641 at rudkx.com> wrote: > > Besides, the git-svn readonly bridge is a great solution for those who want to use git > > It seems to be a reasonable solution for those individuals who > want to use git, but in my experience not for organizations that > want to use git, e.g. have a local server with local branches, > with many people banging on that while at the same time > continuously merging the LLVM mainline in. > > Perhaps your experience has been different - I have limited > experience with git-svn and git-p4, but have found both to be > useful only for me working individually. > > Mark > > Have you considered mercurial? > > I am not as "current" on git wizardry as I am on mercurial, but at I > least verified that branched development and rebasing to tip, r-w- > works on the mercurial-svn bridge (i.e. you can commit directly to svn > via hg and gain all of the benefits of using a dvcs)git-svn allows commits to svn directly from git. But you need to make sure the history in the branch you dcommit from is "linear." As you say, a rebase is always necessary while with "normal" git it is optional. The practical consequence of this is that the developer has to keep some sort of special "upstream" branch that only takes merges from other git branches and always does a rebase against the current upstream svn. That rebase should NEVER be made public to other users of the git mirror (or any clones) for the same reasons that rebases should never be done against publicly-visible changes. In addition, the dcommit produces a history divorced from that in the git mirror because by definition the hash produced in the git-svn mirror is different from the hash produced when you committed the change locally. This is so because you had to do a rebase before the dcommit. Thus on subsequent updates from master, it is not unusual to see conflicts in code you just dcommitted. I don't know whether Mercurial handles this better but I don't see how it possibly could given svn's limitations. But then I am a DVCS newbie. :) -Dave
> Have you considered mercurial?Please lets not go there. I have to use mercurial form time to time in another project and it is really painful. I use hg<->git bridge as often as possible, but it doesn't work as well as the git<->svn one. Cheers, Rafael