On Oct 29, 2005, at 11:08, Julien TOUCHE wrote:
> i know this kind of stuff is more for file configuration versionning,
> but i permit to ask. why not not having a feature when checkout (and
> updating) in an existing non-versioned tree to move file to
> <file>.orig
> and get file from svn ?
If the existing tree is non-versioned, then you cannot run "svn
update" on it. You will get this message:
"Skipped '.'"
If you're talking about running "svn checkout" on an existing
directory, where the directory to be checked out has files of the
same names as files that are already present, then you will get
errors like this:
"svn: Failed to add file 'foo': object of the same name already exists"
And if you're talking about running "svn update" on an existing
working copy, then there is no need to maintain any backups because
they're already in the repository; you can simply "svn update -r$FOO"
where $FOO is the previous revision you want to revert to.
> the file is backup in a same way as perl file replacement .bak
>
> perl -pi.bak -e "s/Old/New/g" file
>
> like
>
> svn co -i.bak svn://server/project/trunk destdir
> svn co -i.orig svn://server/project/trunk destdir
>
> we can precise the existing backup could also be added to ignore files
>
> a bit related to
> http://subversion.tigris.org/faq.html#in-place-import
In-place import is a different scenario. In it, you have an *empty*
directory in the repository. You check it out on top of your existing
non-versioned tree to turn it into a working copy. Then you can
selectively "svn add" the items you want to add, and then commit
them. This doesn't sound like the scenario you're interested in.
> in this way, installing a new server, to reconfigure it, you only
> need to
> svn co -i.orig svn://server/project/trunk/unixroot /
>
> existing directories are not moved, but recognized in the svn tree
> existing files are moved to .orig and ignored thereafter.
> all svn files are added
You could probably achieve the behavior you're looking for by writing
a shell script. It would create a working copy in a temporary
location, then compare itself with the existing directory, move any
like-named files or directories out of the way, svn:ignore the
renamed items in the working copy, then move the working copy files
into the existing directory.
Another possibility is that you would be better-served by a tool
designed to version the filesystem. Subversion is not really designed
for that, but someone has used the Subversion libraries to create a
tool that is, which might work better for you. I've never used it as
I have no need for such a tool yet. It's called FSVS and you can read
about it here:
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 Sat Oct 29 17:26:28 2005