To start off, the main thing I *love* about Subversion, that will keep me
coming back for more abuse no matter how many annoying "features" I hit, is
the repository model. Treating binaries the same way as text, and storing a
binary delta for each revision (rather than the usual SCM cop-out of storing
a compressed copy for each revision) has been great for my server. Sending
deltas over the network instead of full-files, when possible, has also kept
the bandwidth down to acceptable levels. Serving repositories over Apache
and DeltaV/WebDAV are also very powerful options.
The one real complaint I have about the FSFS repository is the lack of
accommodation for different file system size limits. If FSFS is on a file
system that maxes out at 4GB per file, we should be able to say so in a
config file, and revisions that end up larger than 4GB should be split
appropriately and automatically. Setting up a pre-commit hook script to
force an error on large commits is not a real fix.
An official "svnadmin obliterate" command would also be very nice. After
that, per-object history depth limits, or revision-range-specific
obliterate, would be even nicer. Not everyone has an infinitely growing SAN
after all. :)
To sum, the thing I *hate* about Subversion is the Working Copy model. I
am in the process of moving to using SVK exclusively as our WC client. I
plan on adding Lock capability to SVK, either as patches or wrapper scripts.
Once that is done, we have everything we need from the command line, and I
will start making GUIs for our less technical users. If you want some
specifics, here are the big brick walls we've hit in our svn client use so
far:
* Almost everything is RECURSIVE! This is a byproduct of the per-folder
Working Copy model, instead of the central WC Cache. Almost every other SCM
sees the benefits of centralized WC cache, except CVS, which is not a good
role model here. :) Folder recursion might be fine on fancy new file systems
like ReiserFS 4, but it's a real pain for those of us stuck in
slow-recursion NTFS land.
As SVK proves, using FSFS for the Working Copy cache is much faster and
better than the current system. My svn Updates take 5 minutes, when SVK
takes 5 seconds. A history-depth-limited version of FSFS might be even
better.
* Unversioned local files, that happen to have the same name as new
versioned files on the repository, break Updates. Updates stop at these
files, and break the atomicity of the Update. The work-around so far has
been to run scripts that search for and delete all unversioned files, but
that is recursive and slow on NTFS. We should be able to set a "--force"
flag to just overwrite these files. Even without the "--force" flag, the WC
cache should be able to update status without error, and without changing
the local file until a Revert command is given.
* Non-conflicting simultaneous changes break Commits. Even though there
seems to be some rule (according to error messages) that every file
committed has to be Updated to HEAD before, "svn commit" will not do this
simple Update preparation step for you. I don't know of any svn GUI client
that does so either. Instead, it kills the Commit and forces you to start
over. This can cause several minutes of unnecessary pain, as the user has to
complete another Update and recursive status fetch cycle. This is very
painful on large commits on large folder hierarchies, in slow-recursion file
systems. Such large Commits on a very active repository can take hours to
resolve.
* It's more rare for us now, but the "inconsistent line endings" error used
to break a lot of Commits for us. We have a tool called CRLF.exe that
recursively fixes all line endings before commit, but letting SVN ignore
these (or spawn CRLF for us) would be far preferable.
* Unnecessary (zero-change) updates take about as long as useful updates.
Again, this is a byproduct of the recursive WC model. Revision numbering in
the WC caches also don't bubble up the folder hierarchy correctly or
consistently, so that makes it almost impossible to script faster Update
methods.
* Lack of merge-tracking and intelligent cross-branch merge options. SVK
smerge is a good model to copy here.
* Lack of options to automate Conflict resolution at time of Update. SVK
does this better too.
The full list is slightly longer, but I think I've covered the main points.
I just thank goodness SVK exists, so I can get the benefits of FSFS, but
still have a decent WC cache.
:) Jared
Received on Fri Jan 19 05:31:55 2007