On Fri, Nov 14, 2008 at 10:31 PM, Juliano F. Ravasi <[EMAIL PROTECTED]> wrote: > That is probably not branching that you meant, but merge tracking.
If you're going to correct someone's use of technical terminology like that, maybe you should explain what you think the difference is? To me, "branching" including the entire process of creating, maintaining, and re-merging branches, which seems to be precisely what Brion means. Subversion doesn't do that as nicely as DVCSes, as far as I know. > Then, Torvalds did that presentation, and for some reason now everyone > is scared of branching in Subversion... go figure. Because before then nobody knew what they were missing. :) > 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 >From reviewing that, it seems to still handle merging as a diff/patch operation. It doesn't copy over the commits, it only copies over the changes. Therefore you inevitably get giant merge commits that clutter up commit histories and/or are impossible to actually review. Correct? This is the really nice thing about DVCS' branch handling to me. > 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. FWIW, here's a very detailed account of how to use git svn and arguments on why it's better than SVN alone or SVK, from someone who switched from SVK to git: "I used to push strongly for SVK, but got brow-beaten by people who were getting far more out of their version control system than I knew possible until I saw what they were talking about." http://utsl.gen.nz/talks/git-svn/intro.html git not caring about directories is not a big deal (we have rather few empty directories in trunk, and most of those could readily be dropped or have an empty index.html or something dumped in them). Copy/move info might be a pain, although of course that would be solved by having more people use git instead of SVN. :D > 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. You evidently dislike git a lot. Others (like Andrew, me, the developers of the Linux kernel/Wine/...) happen to like it quite a bit, and we seem to be in the majority of people who have tried it, anecdotally. I have, by the way, tried Mercurial, and didn't like it as much. That it took public backing by a major figure in the open-source community to get people to see the advantages in DVCSes doesn't need to be held against them. > In this case, SVK has a clear advantage over Git, because you don't plan > to convert the main repository away from Subversion yet. On the other hand, it has the clear disadvantage of being less widely used and supported, I suspect, by this point (maybe I'm wrong there?). And certainly I don't know of any current developers who use it, unlike git -- which is used by two MediaWiki developers now. (Maybe I'm wrong there too?) But I've never used it, and so can't say much about it. There are some things I like a lot about git that SVK evidently doesn't support, like easily rewriting history for private commits. Other notable criticisms gleaned from the page I mentioned above (SVK user who switched to git): "SVK claims on its home page to be distributed, but by everyone else's definition, it's not, because it's not decentralised - there's always an upstream. No, SVK merely offers disconnected operation. If I meet you in the middle of a cruise and we both have a mirror of a subversion repository, I just can't easily, natively share my local branch with you if we're both on SVK. " "git normally stores its repository information under .git at the top level of your checkout. But everything's compressed and the filenames don't resemble the files in your checkout so grep -r and find etc don't hate you." "I don't know about you but I was always running into situations where my ~/.svk/config didn't match reality, and there were no breadcrumbs left in the checkout to do anything with it. I much prefer these floating repositories and there was some talk of adding them to SVK. " > 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. I don't know how much benefit you'd get from tracking these branches on git anyway, when the whole rest of the repo is still on SVN. It would be somewhat nicer to maintain, maybe, but merging it back in would still require a giant merge commit. I haven't done any branching in git, to be honest (only rebasing for private patch sets), so I can't give an informed opinion on how best to go about this even if we stuck purely to git instead of throwing in git/SVN interactions to confuse things even further. On Sat, Nov 15, 2008 at 5:05 AM, Siebrand Mazeland <[EMAIL PROTECTED]> wrote: > Thank you for that elaborate analysis. Aside from functionality comparison, > I find one thing missing that would be important if the MediaWiki project > were to facilitate another tool for SCM: multi platform support. Can you add > some information on that, too, because I know that we have developers on > Linux, OS X, and Windows, and we wouldn't really like to exculde one of > those groups just because of the used SCM tool. Having proper clients on all > major platforms is one of the reasons I really like Subversion for... git works on all Unix-likes (including Linux and OS X) fine by command line. It will also likely work in Cygwin without much trouble (again, on the command line). There are Windows GUIs available for git as well, which are apparently somewhat usable, but they didn't seem as polished as Mercurial's last I checked. I don't know about the others being discussed. _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
