Mark Ramm, el 29 de agosto a las 12:26 me escribiste: > A couple of alternatives to mercurial were suggested. SVK would work > on top of the existing infrastructure and provide some of the same > benifits. But I see a couple of disadvantages here. SVK is harder > to install and maintain, and is slower than mercurial. It's also not > been well maintained as an open source project and I am hesitant to > invest our collective energy in using it when it's very likely that it > will wither and die. > > Another suggested alternative is bazaar, and this is a much more > compelling story on some fronts. There is a bzr svn plugin that lets > bzr treat a svn repository as a branch, so we could use that to > maintain our existing svn repository structure but get some bzr > advantages. Also the launchpad integration is nice.
Some words about git (to add some more salt to the discussion :). git svn is a great tool for migration/git-svn coexistence. With git svn you even can keep the svn as the "real trunk" and do all the branching in a git repository, completely maintaining "backward compatibility" for people using svn. This is great for any migration (specially, users minds migration =). For example: I can do: $ git svn clone http://svn.turbogears.org/trunk/ tg Now I have a git repository with all the tg's trunk svn history. I can do git branch, git commit, etc. It's just a git repository to me. When I have a branch ready for "upstream commit", I just can make: $ git svn rebase # aka svn update $ git svn dcommit # aka svn commit on steroids git svn rebase, pull all the new changes from the svn repository, and rebase my changes over them. git svn dcommit commit every local git commit that's not in svn to "upstream" svn (you can manipulate svn branches too, I don't include it in the example to keep it simple). So, if you publish you git repository, you are now migrated to git, and people can clone the git repository, do their own branches, do their local commits, send you patches via email using git send-email, publish their branches so you can pull them and be happy in general. As long as there is only one "entry point" (or "sync point") between the svn repo and the git one, people can still make commits to the svn trunk, and keep doing their lifes without even knowing that a git repo exists. They can do svn updates and checkout too, of course. All you have to do is a git svn rebase on the "official git repo" and all the people who has cloned it, can see the changes too. I found this feature very useful and successful in migrating svn repos to git. I don't mean to add more noise to an already hard decision, but I thought you should know the git goodies (if you don't already know them) before you decide about a new SCM =) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- So you run and you run to catch up with the sun but it's sinking. Racing around to come up behind you again. The sun is the same in a relative way but you're older, Shorter of breath and one day closer to death. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
