[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Things I wish SVN did better

From: Thomas Harold <tgh_at_tgharold.com>
Date: 2006-08-13 16:00:33 CEST

A lot of this is self-inflicted pain, but the SVN command-line help
doesn't always show how to fix (or even pointers on how to fix) the
issue. Or SVN makes you jump through additional hoops where it really
doesn't need to.

1) Admin adds /etc to a SubVersion repository (a noble goal), but isn't
careful to exclude Gentoo's "._cfg*" files before committing. SVN lacks
a clean way to remove these "._cfg*" files from the repository without
causing issues in the working copy.

There should be a way, without copying files around on the host, of
"unadding" files from version control. Whether that is an additional
flag on the "del / rm / remove" command that tells SVN to leave the
working copy alone or an additional "unadd" command...

2) Gentoo has a script called etc-update which will auto-merge simple
changes caused by new package updates. Unfortunately, if the admin
added any "._cfg*" files to the repository, there are copies in the .svn
folders and etc-update will auto-merge those as well. This causes
issues such as "Checksum mismatch" when you go and try to check in
(because the local pristine copy has been obliterated).

What's the command to force SVN to refresh the ".svn" folder contents
from the server without touching the local working copy?


Managing /etc (and other O/S folders) is a bit of a special-case use of
SVN, but it's a very handy feature. The problem is that it's a
different mindset then a developer's working copy. For a developer,
deleting the working copy and starting fresh from the repository is an
easy task with low risk. Or creating a 2nd working copy in another
folder isn't a big deal. For a system administrator, the working copy
is very important and somewhat irreplacable. The system administrator
is more concerned that SVN tracks the changes in the working copy rather
then the working copy tracking the changes in SVN.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Aug 13 16:02:08 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.