Eric Botcazou <[EMAIL PROTECTED]> wrote: > I've never created/managed branches or tagged anything in the GCC > tree. The important things to me are: > > - time to do a complete check-out on mainline/branch
Check-out is 30% slower because of the time needed to write the duplicate local copy. On the other hand, there is a nice option "svn switch" which lets you switch a working copy tree from mainling to any branch and viceversa just by downloading the delta between the two, so much faster than checking out everything from scratch. I can think of this workflow: - svn co path/to/mainline patch-sparc-frame-pointer (checkout pristine tree to work on a specific patch) - Write/test patch on mainline. Review/commit it. Committed as r1234567 (single number identifies changes to 10 files, 1 rename, 2 deletions). - From within .path-sparc-frame-pointer directory, svn switch path/to/gcc40branch (switch to 4.0 branch) - Backport patch: svn merge -r1234567 /path/to/mainline (automatically rename, delete, apply modifies). - Test/commit. - svn switch path/to/gcc34/branch (switch to 3.4 branch) - etc. So, even if the initial checkout is slower, you have to do it less often. > - time to do an update on mainline/branch When updating, cvs/svn first try to find out what needs to be updated (in rough terms) and then start downloading the updates. The latter part (download) is obviously the same, as they both download compressed delta over the network. The former part is many times faster in svn, and takes the same time on branches or mailine (while CVS was much slower in the branch) You'll find out that, after you type "svn up", it'll start downloading the first file *much faster* than it used to do with cvs, especially on a branch. > - time to do a diff on mainline/branch "svn diff" is a disconnected operation, requires no server access, so it takes milliseconds. "cvs diff" is dominated by network connection, so it can take a while. Also "svn diff" can handle new and removed files, as you can easily do "svn add/svn remove" on any file, since they don't write anything to the server. Also, the new "svn status" (which is not like cvs status) shows you the current status of your working copy (which files are added, removed, modified, unknown) in milliseconds because it's a disconnected operation (again). > - time to do a commit on mainline/branch Again, much faster in SVN, and it takes the same time on mainline/branches. CVS used to do pretty slow at this. > - space needed locally for mainline/branch Each working copy will take twice the space amount. If you add that to the usual build directory associated with each tree, the difference in "space-per-real-word-tree" is smaller, but it's still very noticeable. This is issue will be probably fixed in newer SVN versions. For now, if disk space is critical, one solution would be to use the 'svk' client tool, which offers many other benefits. > - portability of svn to non-Linux systems This has been answered already. It should not be an issue. Giovanni Bajo
