On Aug 13, 2006, at 16:00, Thomas Harold wrote:
> 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...
I can't find a bug for that, but it's come up on the list a few
times. It's easy enough to do yourself though. To have Subversion
"forget" foo:
svn export foo foo.tmp
svn rm foo
svn ci -m "removing foo from repository"
mv foo.tmp foo
> 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?
I'm not aware of any such command. The contents of the .svn folders
are sacred to Subversion and it is built on the assumption that they
will not be messed with. The files in the .svn directories (in the
prop-base, props and text-base directories) are named with different
extensions (.svn-base and .svn-work) such that if you are doing a
global find and replace on all *.foo files, you won't accidentally
muck up the files in the .svn directories as well. However if you're
searching for files based on a prefix, not a suffix, as you imply
Gentoo does, then that's going to muck up the svn files.
> 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.
Perhaps FSVS is more tuned to these needs?
http://fsvs.tigris.org/
---------------------------------------------------------------------
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:37:33 2006