At 08:03 AM 08/07/2005 +0200, Norbert Unterberg wrote:
>2005/7/8, Jonathan Gilbert <o2w9gs702@sneakemail.com>:
>
>> Anyway, I'm happy to see someone else who agrees with me that redoing a
>> working copy from scratch, including manually copying over edited and
>> unversioned files, is annoying and that even if it means re-downloading
>> everything from the server, automating the process is worthwhile :-)
>
>I fully agree. I see two other cases where I would have liked this feature:
>
>* Create a new project in the repostory from an existing directory tree:
>This can be done by svn import, but then your tree is not a working
>copy. You need to delete (or rename) the tree and then do a fresh
>checkout. With takeover, I would just run an svn takeover on the same
>folder an I am done. I don't care about the double download, we are
>working on a LAN.
This can already be done with a trick I learned from the folks on the
freenode IRC channel :-) Start by simply creating an empty folder in SVN
for the project. Then, counter to your intuition, do a *checkout* of this
folder overtop of your existing project. Since it has no files yet, there
will be no conflicts, and an initial .svn subdir will be created. Then, you
can use 'svn commit' to add the tree to that empty folder as revision 1. :-)
>* Sync a SVN wc with CVS.
>This was done in our company when we started migrating from CVS to
>SVN. I created a folder that was a WC for both SVN and CVS, by copying
>a SVN WC over into the CVS WC. It would have been much easier to do a
>scn takeover on the CVS working copy!
This is precisely why I created the feature in the first place, except that
I was starting with Visual SourceSafe working copies. I can no longer reach
the Visual SourceSafe server, but not wanting to lose my histories, I used
a migration script to import the VSS "database" into an SVN repository.
This is where 'svn takeover' comes into play :-)
>Question: Since takeover and checkout are very similar, why creating a
>new "svn takeover" and not a "svn checkout --force"?
Well, to me, it feels like a separate command, because semantically it does
a different thing, even though the underlying operation is similar. If you
consider also that subsequent additions to the codebase might make 'svn
takeover' avoid redundant file transfers by checking the checksums of
existing files, or even, as was mentioned in another recent post, use
something akin to 'rsync' to bring 'text-base' into a consistent state with
a minimum of network communication, then it begins to feel more like a new
feature in its own right. It also gets its own abbreviation: 'svn to' as
opposed to 'svn co' :-)
Of course, it makes little difference either way in terms of the source
code, so if you and other people think it really should be a switch to the
existing 'checkout' command, it's not particularly difficult to do that.
(It *is* marginally easier to create the separate command for it, though
:-) A new entry in the list of commands, using 'checkout' as a template,
was all that was needed to produce the new option, even in the 'svn help'
listing.)
Jonathan Gilbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 8 10:50:10 2005