On 2007-December-10 , at 00:14 , bulia byak wrote:
On Dec 9, 2007 7:37 AM, jiho <jo.irisson@...400...> wrote:
- speed: given the development model of Inkscape (which is not likely
to change only because of a new SCM system), svn get mainly two things wrong IMHO: speed (committing is slow, diffing is a nightmare...
Really? For me svn diffs instantaneously, and it does not even require internet connection for that because it diffs with its own backup copies.
In the case of an svn diff between the working copy and the current changes yes, this is fast, but as soon as one gives an old (<HEAD) revision number to diff with (e.g. svn diff -r 1600 somefile) it requires network access and is slow (and I have a LAN internet connection so it's probably the server's fault). It is even worst when diffing a whole directory (which is usually very useful). It's even worst for logs: all require network access. These two "features" combined make tracking changes in previous revisions (for bug tracking or similar activities) long and far from enjoyable. Bug tracking in itself is not really enjoyable (IMHO) so it should be made as easy and quick as possible.
Committing does take about a second per file, but I guess it's about as fast as possible for any internet transaction over my connection. It's about as fast as loading a moderate-sized web page.
Committing to the central repository (i.e. pushing in the case of git or bzr) is probably the only operations in which subversion can match the others, since the limiting factor for all is network access. But the fact that distributed scm commits (i.e. local commits) are very fast is good for committing often. It allows to keep track of smaller changes, possibility breaking things but keep it invisible from the others. Then, only when you changes look good and are stable can they be actually "committed" (pushed) to the central repository. Basically you can use commit as a stronger and safer "save" command and this looks very useful.
Just my 2 cents.
JiHO --- http://jo.irisson.free.fr/