There’s a lot of contextual information in those changes which SVN has completely and utterly forgotten.
#SMARTSVN REMOVE FOLDER FROM WORKING COPY SERIES#
But the merged files didn’t magically drop from the sky - we made a whole series of changes to get them where they are. Merges basically take diffs from the common root and smash the results together. Subversion’s world revolves around revisions, which are snapshots of the whole project.
The fatal mistake in the merge process is one I didn’t fully understand until reading HgInit (several times). There are essentially two problems in merges: the actual merge process, and the metadata about the merge. What tends to happen is people gloss over why they’re broken. Everybody knows merges are broken in Subversion and that they work great in distributed systems. Simple as that! If only merges actually worked. Do everything you need, with as many revisions as you want, and then merge to trunk. Private branches are supposed to be the solution to this problem of work-in-progress revisions.
In general though, we are working on high availability environments and making a round trip to the server is not a big deal. It has exactly two reference points: the revision you started with and the working copy. Subversion cannot queue up revisions locally.
This is fine as long as you’re in the office, but it fails the moment you’re traveling or your connection to the server fails for whatever reason. The caveat is that this always requires server round-trips, which is okay as long as you’re in a high availability environment with a fast server. Subversion understands this perfectly well, and the mechanism for doing so is branches. When I’m working on something complex, there are a lot of points where I want to freeze frame without actually telling the world about my work. However, a lot of those revisions are not really meant for public consumption. It can be a solution, but the problems reach a bit beyond that.įundamentally, a commit creates a revision, and a revision is something we want as part of the permanent record of a file. I don’t want to compare to git or explain why it fixes the problems, because that has the effect of lensing the actual problems and additionally the problem of implying that distributed version control is the solution. It’s important to understand what the flaws are, and in particular I want to discuss them without advocating for any alternative. A perfect product is a product no one uses, after all. And like any real world production system, it has a lot of flaws in nearly every respect. Nevermind the hyperbole, SVN is good by practically any real world measure. It’s a mature, well understood system that has been and continues to be used in a vast variety of production projects, open and closed source, across widely divergent team sizes and workflows.
#SMARTSVN REMOVE FOLDER FROM WORKING COPY PATCH#
SVN is a long time stalwart as version control systems go, created to patch up the idiocies of CVS. This post is motivated in part by Richard Fine’s post, but it’s a response to a general trend and not his entry specifically. I myself wrote a series of posts on the subject, but I skipped over the reasons WHY you might want to switch away from Subversion. Recently there’s a lot of momentum behind moving away from Subversion to a distributed system, like git or Mercurial. I’ve used Subversion for a long time, even CVS before that.
0 kommentar(er)
