Ryan Schmidt wrote:
>
> 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
Thanks, I'll explore what the export command does. I think I understand
what it does, but I'll take that opportunity to read the handbook again.
> 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.
Yeah, and it's mostly self-inflicted pain (adding the ._cfg* files to
the SVN repository in the first place). It does make me wish for a
"force SVN to verify and fix the local .svn folder" command because it's
very easy for users to damage files within the .svn folder. Mostly
because SVN is storing that information in the same location as the
working copy.
Which makes sense from a design point and is similar to CVS, IIRC. But
there are times like this when it proves to be a bit fragile.
>> 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/
Perhaps. The main advantage of SVN is that it exists in Gentoo portage
as a package (one that is, hopefully, well tested). So installation is
very easy and pretty much foolproof.
It's been an interesting learning experience trying to use SVN in this
manner. One advantage is that I can use file-based repository access
without dealing with the complexities of SSH / SSL / Apache / WebDAV.
On the whole it works well, but rectifying simple mistakes such as
adding the wrong files to SVN or having etc-update clobber files within
the .svn folders has taken me a few hours to fix.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 14 17:25:15 2006