Jonathan Gilbert wrote:
> 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 :-)
The difference is that with SVK, I can commit multiple changes to my
mirrored copy and only later connect to the `Net and transmit the
changes (individually or as a single commit) to the remote repository.
Subversion offers no such capability.
> 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!
Indeed; I was only discussing the ability to "import and make a working
copy in one pass" that SVK has (which is one part of what 'svn takeover'
is intended to cover).
> 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).
I am responding to the original description which was that the user has
a working copy checked out from some other version control system and
wishes to convert that to a Subversion working copy. I don't see how
there is any way to avoid all network communication while converting (at
the very least the client and server must communicate checksums and
directory/filenames). What I was suggesting, however, was that this
behavior seemed more like a special case of import, rather than
checkout. I think it would be less coding to add the ability to
generate .svn files to import, then add a function to import to permit
importing over an existing repository file (this is how SVK does
imports, FWIW).
To associate a selection of files with a Subversion repository (building
the admin files on the fly) would seem to require turning the checkout
actions inside out:
1) client asks server for contents of current directory;
2) client compares checksums from files it already has with checksums
that the server provides and builds matching .svn/entries records and
text-base (from the local file, not from the server);
3) for all files where checksums differ, client retrieves fulltext from
the server and creates a text-base, then leaves local file as is (i.e.
with changes);
4) for all files which exist on the server, but not locally, retrieve
the text-base and mark the .svn/entries record as locally deleted;
5) for all files which exist locally but not on the server, the client
code does nothing.
The only time that any file needs to be transmitted in full is the
missing or locally changed case. But this is a significant alteration
of current behavior (even if the pieces are all there already). I don't
see how adding rsync helps at all).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
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:58:04 2005