At this time, when I upgrade from the old cvs to the shiny new svn; I can't help but compare the experience to real changesetbased and disconnected revision management software.
You all know the problem; you are away from internet and still want to hack on your project. If you are anything like me then you depend on your revision management system for a lot more then simply committing your work at the end of the day.
For example; I check what changes I made, or revert to the latest committed version quite often, since that allows me to be quite destructive in my search for the perfect way to do this bugfix, or this new feature. Due to this behavior I also commit a LOT more often then just at the end of the day; a typo-fix is one commit. A repaint fix is another and that new feature is definitely a seperate one.
I went looking for a revision management system that supports this all the way back when all I knew was cvs. The moment svn hit 1.0, I downloaded a generic book on the software from O'Reily and read through it. I was highly dissapointed. svn is like a cvs v2. All known problems are fixed (and some new ones introduced) and thats it. Feels like upgrading from W95 to W98 (or office97 to officeXp). Not something I'd do unless I really had to.
Some time ago I found darcs (www.darcs.net) as an alternative; I immidiately fell in love with it 
Its incredably usable, simple to use and much more powerfull then cvs or svn!
Its disconnected nature is my number one feature. Its not clear why thats usefull until you actually start using it and start adjusting your workflow in ways you never thought was appropriate before. The commit action you know from cvs is devided into two parts in darcs; you record your changes first (giving it a comment and all that) and then you push your changes to a central repository as a separate step. Since its 2 commands you can record more then one item before you push your changes. This is immidiate usefull when you are not connected to the internet! And you definitely will commit more often if you never have to update before you commit, since committing itself takes seconds since there is zero internet traffic going on.
Oh; how often do you create a branch? Branches is one of the reasons KDE is switching source management software, in cvs they suck; in svn they suck just as much; but are at least much more visible (a mixed blessing). After doing branches in darcs you'll agree that that is the real way to do it. Just do a new checkout and start committing there and you have yourself a branch. Since each checkout is a repository (complete with history) in itself the patch-flow is only limited only by your imagination.
For example; I have a project (pvr) that runs on a dedicated machine with a tv-card, which is located in my living room. I develop on my workstation and whenever a patch is finished I push it to my pvr, over the network. After testing it on the real hardware I either amend the patch (re-record, if you will) or I push it directly to my server which contains the main repository. Any patch not-yet-pushed to the server still needs to be tested.
At the end of the day KDE is the largest svn repo out there, and darcs is just a new kid on the block which probably makes it a bad choice for us. Not to mention that there are known scalability issues that need work in darcs anyway. So; darcs is getting there, but not just yet.
What does confuse me is why people say svn is changeset based. There is indeed a global revision number, a commit in kdebase will make koffice get a new revision number as well. But thats it. None of the advantages of being changeset based are present!
First scalability; if there have been 10 commits (changesets) that I still need to download to my laptop, the only thing darcs does is check the list of patches, and download those 10 patchsets. Svn checks version for each and every file in the project.
My darcs changes list is a project wide list and that makes an update take the same amount of time if I was managing 1 file or if I was managing 1 million files.
Second; what is a changeset? When a number of files are changed and commited in 1 commit, those files together make a changeset. They are combined because downloading only a part of that changeset would be useless. Think moving a method from one file to another, you need to update both files at the same time or your compile will break. For this reason all updates should be project wide; never should you be allowed to update just one directory. It can break your compile.
So; svn surely is not changeset based (it just happens to manage them), then why is it an advantage to have project-wide numbers in svn exactly?
update Asking this question on #svn, I got the answer that indeed svn is not changeset based, it just has a backend that kind of looks like it does. The global numbering is just one way to allow (directory) renames, there are not really any advantages besides metadata-management.
Syndicate Blogs
down?
Any comments on the unavailability of anonsvn.kde.org via svn?
[edit: working now]
Version number for each file
This is something I found out only now in the KDE repository, even though I have been working with Subversion for some time: it reads the version number for each file in your local copy.
So, if I do "svn status" in my trunk/KDE, I can switch to another terminal, run 'top' and watch the svn process grow about 2MB/s to 75MB VSZ before it starts to even show anything on the screen.
The same is true for other commands, like svn up, svn diff, etc.
The most annoying thing, though, is that Ctrl+C is useless for those of us who use HTTPS. libapr simply ignores it, so I have to resort to Ctrl+\ (and then svn cleanup).
uninteruptable svn
This is not a fault of apr or svn. In all neon versions before 0.25 neon blocked ctrl+c. neon 0.25 fixed this issue. just atm you cant use neon 0.25 with svn due the api changes in neon. they are working on solving this issue.
darix
zander, I think the answer to
zander, I think the answer to your questions can be found in this subversion FAQ:
http://subversion.tigris.org/faq.html#changesets
I can answer more questions about this if you want.
-Ben
I have played a lot with Darc
I have played a lot with Darcs too and I am using for local projects. I have to say it is very cool since its like Monotone or arch but with a more cvs-like command set. The problem with those systems is that tend to concentrate more on patches than history, I still haven't discovered how to browse history in Darcs, altough in monotone is more easy.
I think SVN is what KDE needs. It solves what people complained for, specially coolo when doing admin stuff by request. No need to introduce new use cases until they appear naturaly. They, however, should be explored by developers for personal/business use.
SVK provides a descentralized interface to SVN, basically you make a SVK repo, commit on it and then sync with remote repo.
The global number has to do with SVN versioning the whole repo and not just files. If I commit, branch, commit in branch, the last commit number will not appear in trunk history, but in can represent more than file changes, like moves or renames, when merging, the unique number represents ALL the changes done in the repo in that commit, which are atomic btw.
global commits
first; the way to browse the history in darcs is pretty powerfull, but not directly obvious to people that are used to browsing file-based. Try 'darcs changes' or 'darcs annotate -p patchName'
The global name you say are about the whole repo; well that was clear to me already, I am just not clear why that is an advantage. The points I made in my blog above state why its usefull to do patchsets in things like tla/monotone and darcs. But svn doesn't exploit those, so I fail to see the usefullness of the function.
I'm also quite sure svn up does not do things atomic. My kdebase is a higher version number when a kdelibs commit has been made, but my kdebase checkout has not been updated. So 1 commit changing all the COPYING files in kde can be fetched by users completely independently, which surely is not atomic.
Thanks for your response!
svk
You probably already know this but svk (http://svk.elixus.org/) is a decentralized version control system that uses Subversion. You can use it with the KDE Subversion repository and do all the offline/local branch stuff.
That might ease the pain a little.