At 03:48 PM 12/07/2005 -0400, you wrote:
>Jonathan Gilbert wrote:
>> As I understand this, though, it doesn't apply to scenarios where projects
>> -- including their histories -- are imported using an external tool like
>> cvs2svn or vss2svn.
>
>That's a different use case. There is no way that the 'svn takeover'
>situation can be compared to conversion from another version control
>package.
The 'svn takeover' command is intended to be used after a separate source
has duplicated (with history, typically, though it's not a requirement) a
separate VCS's repository into an SVN repository.
>> Does this command actually avoid the *network bandwidth* of retrieving a
revision from the SVN server?
>
>No of course not. The data still has to be transferred from the master
>repository to the mirror. Once sync'd, however, all traffic is local.
>SVK was developed primarily as a distributed version control system; I
>can mirror a half dozen packages from a variety of remote repositories
>to my notebook, then work on patches offline (say on a long flight).
This kind of development is possible with regular SVN as well; this is
essentially the main reason it *has* the '.svn' subdirecotry in the first
place :-)
>My point was that the thing that is keeping Subversion of easily
>providing a 'svn takeover' functionality is exactly what SVK has
>already: no embedded admin directories. However, with that, you have
>the disadvantage that every client has to have a local mirror of the
>remote repository.
The main thrust of the 'svn takeover' command at this point is to eliminate
the redundant data transfer for people who already have complete or
mostly-complete working copies. This is entirely different from actually
mirroring an entire repository and using a local server!
>I think that the best way to resolve the specific case that 'svn
>takeover' is supposed to be resolving (import an existing working copy
>from some other VCS package) would be to extend import to recursively
>build the .svn admin files as the files were imported. [snip]
You have misunderstood 'svn takeover'. Its purpose is not to place files
into the repository, nor is it to copy a revision out of the repository.
The purpose is to avoid such unnecessary work in the situation where the
files are already in the repository, and the user already has a copy of
them which is not an SVN working copy (because it does not have valid
'.svn' subdirectories).
At this point, I'm not too concerned about the move some people have
expressed a wish for in which the '.svn' subdirectory no longer requires a
'text-base'. I'm trying to create a way to build up the 'text-base' against
an existing WC, without clobbering files that are different from the
repository in the user's copy and without requiring the user to manually
move unversioned files into a freshly-checked-out SVN WC. There is also the
concern voiced by people working with extremely large projects. I have
heard quoted a 19 gigabyte working copy that, without a bandwidth-saving
form of 'svn takeover', can only be made into an SVN WC by transferring 19
gigabytes over the local network!
I agree that it is definitely a corner case, but it is a situation that
people other than myself have found themselves in. One of the main alleged
purposes of computers is to reduce the amount of toil users are required to
do, and this is precisely why the proposal for 'svn takeover' exists.
Jonathan Gilbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 12 22:31:53 2005