Le jeudi 26 février 2009 à 16:10 +0100, M.-A. Lemburg a écrit :
I didn't know that and was under the impression that those other systems simply hook up to the svn repo via the standard Subversion interfaces.
They hook up to the svn repo for mirroring purposes, true. But they also have their own wire protocol, and some of them also have Web-based browsing facilities (which, in the case of Mercurial, are actually two sides of the same coin: the same base URL is used for human-readable browsing and for read-only HTTP-based cloning of the repository (the writeable cloning variant, as with SVN, uses an SSH-based protocol instead)).
However, it is often said that branches in DVCS system are so much better to work with. Subversion supports these as well, it's just that we currently don't make much use of them and that's what I wanted to point out.
Perhaps because they are not really practical? For example, I don't know how often you use svnmerge, but it's surprisingly slow even for small merges. It also seems to transfer lots of information over the network.
I don't understand that comment. Of course, you can commit whatever changes you make to the branch.
Ok, sorry, I misunderstood your comment.
By contrast, the reasons for switching from CVS to Subversion were mostly technical ones - we often had problems with locks and tagging was very slow.
There are also technical reasons to prefer a DVCS: fast logging, fast annotation, fast (and supposedly smarter, although I'm not really knowledgeable on this) merges, and in some cases a nifty Web front-end.
Why is that ? You need to do that for patches that change the build system or configuration, but for patches to a single C file, that's normally not needed.
Ok, but the point is that if many files have changed (or a single file in the Include directory :-)), the rebuild process is longish each time you "svn switch". Not so if you use a separate directory for each line of work.