Slashdot Mirror
Subversion 1.5.0 Released
Hyrum writes "The Subversion team is proud to announce the release of Subversion 1.5.0, a popular open source version control system. The first new feature release of Subversion in almost 2 years, 1.5.0 contains a number of new improvements and features. A detailed list of changes can be found in the release notes. Among the major new features included in this release is merge tracking—Subversion now keeps track of what changes have been merged where. Source code is available immediately, with various other packages available soon."
Subclipse 1.4.0, which works with Subversion 1.5.0 has been released. TortoiseSVN release candidates that are compatible with SVN 1.5 have been out for a while, and the plan is to release TortoiseSVN 1.5.0 this weekend.
Those (along with the SVN commandline client) are probably the most popular clients, so most people won't need to wait "a while".
There's also Mercurial, which maintains a command syntax similar to Subversion, but uses distributed repositories. With it one can easily create a local repository suitable for offline use, including access to the full project history.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
Out of interest, why do you use multiple clients on the same working copy? Isn't that somewhat unusual?
Absolutely not unusual. I use both the SVN command line client and TortoiseSVN's client on my windows boxes.
TSVN is great for working with individual files and doing the normal tasks of updating a single directory, or checking in files, or doing diffs, browsing the repository, or looking at change logs. Basically, we use TSVN for all of the interactive grunt work that goes on during our normal working day.
The SVN command line client, OTOH, is great for scripted things. Like running "svn update" on all of my working copies at 2am overnight - so that I have the latest changes from everyone else when I start working in the morning. If anyone added huge bulky files to the repository yesterday, they get downloaded overnight without my having to wait. And it speeds things up the next day so that when I use TSVN update, odds are good that I'll already have the latest revisions on my hard disk.
The change in working copy also happened when SVN went from 1.3 to 1.4 - so it's not a new issue. We all had to wait for our tools to be compatible with 1.4 back then as well. I think there were also changes on server-side back then, so if the server spoke 1.4, you had to use a 1.4 client. But you could leave the server at 1.3 and use 1.4 clients (backwards compatible), and then upgrade the server to 1.4 once you were done with client upgrades.
Wolde you bothe eate your cake, and have your cake?
Only if the different clients operate on the same working copy. If you have a different working copy (checkout) for each client you're fine. The repository is not auto-upgraded.
-- Ed Avis ed@membled.com
why do the instructions tell you to manually track the merge revision numbers yourself? http://svnbook.red-bean.com/en/1.1/ch04s04.html#svn-ch-4-sect-4.1
Because the instructions you quote are for SVN 1.1.
You don't want to use svn with a large tree because it stores a second copy of only the revision you checked out (so that diffs are fast). Other systems like hg can typically store the entire repository, giving you access to all revisions, in less space (it's compressed) than svn can store just the working copy.
Furthermore, this second copy is stored in the same folder tree, which is both annoying (from a tools pov, like grep) and slow (OS has to stat a lot more inodes).
You're painting this far too black and white.
Distributed systems have their own set of limitations, some of which centralized tools don't have. Some development processes cannot be implemented with distributed tools, pretty much the same way as processes such as how the Linux kernel is developed cannot be implemented by centralized tools.
For example:
Let's say I wanted to make sure that any change going into my project enters the main line, or "trunk", first, and is then applied to release branches if necessary. This makes sure that I have one common place to log all changes ever entering my code base. That's very simple requirement, right? This approach is used by many projects, e.g. by all the BSDs, and by Subversion itself. Let's say I picked Mercurial as my tool for the job.
So I have a changeset on my trunk, and I want to merge it into my 1.x and my 2.x release branches. I will first need to pull the change from trunk into my branch, right?
Wait... why does it say "up to which"? I just want that one change!
Darn, turns out that in Mercurial, changesets depend on all their ancestors in order to guarantee integrity of all changes I pull from another clone of my repo. You cannot pull a change without having around its parent, since revisions are identified by hashes in order to be globally unique across all clones. The hash of a revision is derived partly from the hashes of its parent revisions (they are included in the manifest).
So I need all parent revisions of my changeset in my branch. Since I've forked off my branch from trunk, and have not yet made changes to the branch itself (remember that all changes to the branch should be coming in via trunk), Mercurial will see no conflicting heads and simply forward my release branch to the latest head of trunk. So I can either pull every change I've made on trunk since forking the release branch (not much point in that), or manually apply a patch to the release branch (i.e. side-step the tool).
Well, great. With Subversion 1.5, all you need to do to get a changeset, say rev 42, from trunk to a release branch is
So in practice, people using Mercurial end up fixing problems on their release branches, and merge the fixes to their main line later. And yes, it seems like you have to manually apply a fix to all your release branches separately (at least I haven't yet found another way).
In all fairness, there is in fact an extension that allows Mercurial to "transplant" a changeset from one branch to another without requiring you to also merge all the parents of the changeset: http://www.selenic.com/mercurial/wiki/index.cgi/TransplantExtension
This extension maintains a special file mapping local changeset hashes to remote ones. You have to bet your luck on not ever creating the same hash for two different revisions, though, otherwise your project's history is borked (I have no idea how likely this is).
Certainly, maintaining a separate list of changeset ids is not something intended in the original design, which focused on providing distributed branching and merging. The design does a very good job at this no doubt. By making sure that all bran
You don't want to use svn with a large tree because it stores a second copy of only the revision you checked out (so that diffs are fast). Other systems like hg can typically store the entire repository, giving you access to all revisions, in less space (it's compressed) than svn can store just the working copy.
.svn folder for easy diffs. Which was designed to reduce the amount of server traffic. I'll agree that sometimes that's not always a good choice, but (for the most part) local disk space is inexpensive and the 2x space requirement on the local disk doesn't bother me.
.svn folder in the root of the working copy and nowhere else.
SVN works fine with large trees (whether that's measured as # of revisions, # of files, or # of bytes).
Yes, the working copy stores a "pristine" copy in the
There's been some talk about allowing the user to tell SVN (and tools built on top of the SVN libraries) that there may not always be a pristine local copy. The question, I think, is whether it could be done without breaking other design goals (the ability to be a WebDAV source comes to mind). Or without generating huge amounts of traffic (the anti-argument here is that if rsync can do it, svnserve should be able to).
I think there's also talk of putting the
But yes, I'm hoping that they'll switch to storing the pristine local copy in compressed format, which would save a good bit of space. I suspect the design was designed to be conservative with regards to beating on the CPU, and that there were a zillion other priorities to get working first. It's only been in the past year or two that I've seen more frequent mentions of improving the working copy design.
(Being able to have sparse checkouts will probably help us a lot with the local working copy size. It will at least make a dent in it.)
Wolde you bothe eate your cake, and have your cake?
I'll add to your post a point that is often missed, so it bears repeating:
Just because git _allows_ you to do distributed development (multiple repositories) doesn't mean you _can't_ have a single main repository. There can still be one "blessed" version of the code, which is backed up and everything else you like to do with your Subversion repository.
However, if you ever want to make a couple of commits while disconnected from the network, or try something out, making multiple commits along the way, until you can make an informed decision about pushing your changes to the main branch or not - with git, you can. So, even if you don't need those capabilities now, choosing git may still be a good idea.
Please correct me if I got my facts wrong.