At 10:13 AM 18/04/2006 -0400, Michael Sweet wrote:
>Molle Bestefich wrote:
>> ...
>> Therefore I'd like to see a new subcommand, which would convert local
>> files into a working copy. That's exactly the same functionality that
>> Alan proposes: checkout BASE files and create .svn folders, but change
>> nothing else. Just for laughs, let's call this 'svn integrate'.
> > ...
>
>That sounds more like an option to "svn import" - basically, import
>the (current) directory into the specified repo and then do the
>equivalent of a checkout in that directory, e.g.:
>
> svn import --takeover http://foo.bar.com/myproject/trunk
>
>to import the current directory or:
>
> svn import --takeover myproject http://foo.bar.com/myproject/trunk
>
>to import the named directory and setup a WC there.
This is completely the opposite of the original reason I designed the feature.
I used to use (or should I say, be used by) Microsoft Visual SourceSafe. I
didn't know that it was bad; I knew it seemed a lot better than CVS, which
always looked too complicated and UNIX-oriented for me to bother to get
into. However, one day I read an article that described various ways in
which a SourceSafe repository can become corrupted -- in many cases,
unrecoverably so! I did some searching and found out that it was apparently
common knowledge, so I decided I had to switch to something else. Having
recently started development with the 'mono' project, who had just switched
to Subversion, and therefore having had some exposure to Subversion, I
chose Subversion as the replacement. The following were all factors in the
choice:
1. Free -- free of cost, free of guilt :-)
2. Reliable -- one of the most reliable from what I've read
3. Fast
4. Availability of a 'vss2svn' type script
So, here I was with a brand new completely empty Subversion repository and
a hard drive littered with Visual SourceSafe working copies, not all of
which were fully committed to the repository (i.e., some files were
partially modified and thus still checked out). I ran the script, and when
it was done, I had 300-some revisions in the Subversion repository,
including the complete change history with log messages of all projects,
with HEAD equal in every possible way to the latest revision of all the
SourceSafe projects.
A short while later, I had the need to make changes to one of the projects
under source control. I definitely didn't want to use SourceSafe, because
then I'd somehow have to resynchronize and it would be a big pain in the
ass and I was trying to get away from VSS anyway. So, I deleted the .scc
files and removed the +r attribute from the files, effectively cancelling
its VSS working copy status. Next step: make Subversion recognize it as a
working copy. "svn co". Nope, no go. Hmm.. where is the option I want? Hey,
what's going on here? There *is no way to turn this into a working copy*!
For that particular project, I did a checkout into a separate directory and
then moved the .svn metadata directories over one by one, by hand. After
the third project, though, that technique was starting to get a little bit
old. That was when I conceived of the "takeover" feature. I poked at the
Subversion source code and came up with the simplest way to implement it: I
noticed that "svn checkout" was implemented by simply creating empty
metadata files representing revision 0 and then doing an "svn update"
(exactly as though the user had typed "svn co -r 0" followed by "svn up").
I made my change by adding a flag to the internal implementation of the
"update" command to make it simply ignore existing files. The metadata
directory would still get its pristine copy, but the existing file would be
left alone -- after all, not all of the projects were in a committable
state when I did the switch to Subversion. I didn't actually know if it
would work, but I tried it, and sure enough, "svn status" showed those
files as locally modified. After completing those changes, "svn commit"
worked perfectly.
I actually neglected to handle existing subdirectories. I never noticed
this at the time because the majority of my projects are relatively small
and are all in one subdirectory. I've only had to "svn takeover" one
project since then, and while it was a bit of a pain in the arse, it didn't
really take too long. I simply did a non-recursive "takeover" (which,
modelled after "checkout", had inherited that option) of each subdirectory,
and then manually edited the "entries" files to include nodes for the
subdirectories.
As you can see, the use case for "takeover" has *nothing* to do with
putting files into the repository. The files are already there, for
whatever reason, and the local copy of the files -- possibly a working copy
from a previous version control system -- is similar to the server copy
*but may have changes*. For me, the fact that "update" would add missing
files automatically as part of my "takeover" operation was never a problem,
because I never actually *had* other files to be checked out that weren't
already in the local copy. I would be perfectly happy with a "takeover"
that didn't actually place missing files into the local copy, and instead
treated them as having been deleted. As I see it, though, such files should
be automatically scheduled for deletion in the repository; otherwise, the
working copy is inconsistent with the "entries" file and gets tagged, as
mentioned by a previous poster, with a '!' in "svn status".
Here is how I envision the various commands and their behaviours:
svn checkout
Shouldn't change; should still die with an error when an existing file is
found. If any change is to be done, it should be to automatically remove
files successfully added up to the point of the collision, returning the
filesystem to its state before the error was detected. However, I'm not at
all certain that this could be implemented in an efficient way. The most
efficient way I can think of would be to ask the server for another pass
over the same set of files (I vaguely remember that there's a way to do
this without actually receiving the files' contents) and cancel that
request when the erroneous file were reached. I don't have a strong opinion
about whether this overhead would be worth it.
svn checkout --force
Should blindly overwrite existing local files. A user using this option
should be well aware of this behaviour and not use it if he is worried
about losing local changes.
svn takeover / svn integrate
Should *only* set up metadata. A pristine copy is retrieved from the
server, and honestly I don't think bandwidth concerns are important at this
stage. Certainly, an rsync-like algorithm for this would violate
Subversion's consistency guarantees, in that, though it is very unlikely,
the rsync algorithm *can* incorrectly match blocks and generate corrupt
files. As I mentioned earlier, I feel that if the corresponding files are
missing from the repository, they should be automatically scheduled for
deletion.
I've also given it a bit of thought and believe that the output should be
more similar to "svn status" than "svn checkout", since the operation is
logically comparing the existing files with the pristine copy (albeit a
pristine copy that is in the very process of being dropped into place).
Perhaps something like:
box:/> svn takeover svn://server/source/trunk/project
T existing_unmodified_file
TM existing_unmodified_file_that_has_svn_properties
M existing_modified_file
TM existing_unmodified_file_that_has_svn_properties
A existing_file_not_in_repository
AM existing_binary_file_not_in_repository
D file_in_repository_missing_locally
DD this_situation_should_also_be_detectable
box:/>
Jonathan Gilbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 21 18:24:13 2006