Re: [Wikitech-l] SVN update on live sites to r43514, questions on branching

Hello Brion, Brion Vibber wrote: That is probably not branching that you meant, but merge tracking. There have been reasonable merge tracking support available for a long time for Subversion, either through the svnmerge.{sh,py} utility (that is distributed along with Subversion itself, since 1.2) or through SVK (both existed since before Git)... and *nobody cared*! People either branched and merged anyways, like described in svnbook (until 1.5), or a few looked for these handier tools when they needed. Then, Torvalds did that presentation, and for some reason now everyone is scared of branching in Subversion... go figure. Subversion 1.5 incorporates good branching support (not great, or excellent... just good enough). This kind of branch you suggested is quite trivial to handle now in Svn 1.5. It is just a matter of giving another read to chapter 4 of svnbook: http://svnbook.red-bean.com/en/1.5/svn.branchmerge.html The most Subversion-friendly DVCS is SVK. It exists since before Subversion 1.0, and have been continuously evolving along with Subversion since then. It supports the same features that are unique to Subversion, like directory versioning and properties, and uses the same underlying repository, so, it plays really well with Subversion. Your local revisions are a perfect mirror of remote revisions (with the exception of revision numbers). There is Git, which uses a different and conflicting model from Subversion. Git doesn't care about directories, properties and copy/move information, and this makes it easy for people to silently screw up your repository (properties that should be updated aren't, file references that should be placed aren't). Some of these problems can be partially avoided by threatening your co-developers if they don't use --find-copies-harder to git svn dcommit, others are simply disregarded because Git ignores it completely. Bazaar has some so-so Subversion support, but also has other problems. Bazaar doesn't have the notion of a file copy, and also doesn't support all features that are unique to Subversion, so conversion is also lossy. Mercurial has a few ways to communicate with Subversion, all of them still in development. Git has a lot of mind-share, most from people who never cared about distributed development, then watched Torvalds presentation and now think that Git is the best tool for everything, just because "Linus said so". The fact that GNU arch, Monotone, Darcs and SVK were sitting around way before Git was planned is just a minor detail, most of these people will refuse to even consider testing the alternatives to check what they have to offer. In this case, SVK has a clear advantage over Git, because you don't plan to convert the main repository away from Subversion yet. In your use-case, you want public branches and private branches. The git-svn bridge is more intended to be used for a single developer dealing with a public Subversion repository, or with some extra work, a Git-based project to be exported to a read-only Subversion repository. It is not trivial to share Git branches among developers and still be able to use git-svn to commit any of these shared branches back to the central repository. Expect things to break. In the case of the Special:Search redesign, it sounds like a public branch, so it makes sense to have this branch in the central repository. Then SVK can be used, since it understands Subversion branches and its own local branches. SVK merge tracking is still incompatible with Subversion 1.5 merge tracking, so it is a good idea to stick to a single tool for branch <-> trunk merges (private branch <-> public branch merges and other work are fine with either tool). Also SVK mirroring is another strong point. It is way better than the scavenging that git-svn does through svn logs to find what and how to convert the repository. Do you remember that I asked you on IRC about providing an svn dump of the MediaWiki repository? SVK is able to use such a dump to bootstrap the mirroring process, making the initial repository clone *a lot* faster than git-svn. This is all only while you want to keep the Subversion central repo. If you really want to go distributed, SVK would be inviable, and Git is probably not the best option. Best regards, Juliano. -- Juliano F. Ravasi ·· http://juliano.info/ 5105 46CC B2B7 F0CD 5F47 E740 72CA 54F4 DF37 9E96 "A candle loses nothing by lighting another candle." -- Erin Majors * NOTE: Don't try to reach me through this address, use "contact@" instead.