You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Nathan Kidd <na...@hummingbird.com> on 2004/05/20 16:41:56 UTC
[OT] Re: VSS to SVN migration script
Toby Johnson wrote:
> Could you send me the entire ss "HISTORY" command for this file that's
> giving you trouble?
[Somewhat off topic.]
A few months ago tried to convert our VSS databases using
both vss2svn.py (https://chidb01.tallan.com:4430/vss2svn/) and
migrate.pl (http://www.riseup.com/~brettw/dev/), without success. (It
seems our databases were much more complex than what most people were
successfully converting.) I spend time hacking vss2svn.py but eventually
gave up and just did a latest-version import, keeping the old VSS
database for history.
My changes to vss2svn.py weren't entirely useless however, and I notice
a few things I solved there cropping up in
http://www.tobiasly.com/svn/vss2svn.pl.
1. Pertinent to this thread, I documented all the possible vss history
outputs I could find. I'm not aware of any missing 'action types'. See
attached vss2svn.py.patch.historydoc.
2. ss.exe output redirected to STDOUT forces hard return wrapping at 80
cols., as noted in the --flatten argument to vss2svn.pl.
" --flatten : "Flatten" migrated comments so that all newlines become
spaces. If not used, extra "hard" newlines will be inserted
due to word wrapping of "ss" output; unfortunately there is
no way to distinguish between "hard" and "soft" newlines
during migration."
This can be solved by using ss.exe's -o@ option to output to a file and
then read the data from the file. No hard wrapping occurs. This is
particularly important not just for comments: if you have really long
paths in VSS they also will be hard-wrapped! Attached is my patch for
vss2svn.py to do this. (vss2svn.py.patch.nohardwrap)
I made other large changes to vss2svn.py so it understood all the
previously documented history 'action types'. It (the script, not these
particular changes) wasn't in a finished state when I had to move on
("finished" = "converting my database") and the changes are so broad I
don't think they'd be easily accepted as a patch. If someone is
interested in this then drop me a mail.
Regards,
-Nathan
Re: [OT] Re: VSS to SVN migration script
Posted by Toby Johnson <to...@etjohnson.us>.
Jens B. Jorgensen wrote:
> Hey guys! I'm actually the original author (plagiarist? I borrowed
> heavily from cvs2svn.py) of vss2svn.py. We took the directory approach
> because sadly (at through the automation interface) history on actual
> files is incomplete. Believe me, parsing the text of ss.exe was not
> the route of choice! I was originally trying to do it through the
> automation interface as this is much easier but alas it cannot be done.
Yes, I realized early on that VSS's "API" is very incomplete and
inadequate. It seemed everything was geared around setting up hooks for
certain events, but since VSS has no server component, you must deploy
your hook scripts to all clients who use it!
By file vs. directory approach, I meant using ss.exe to get file history
vs. directory history. I'm still using ss.exe (and trying to account for
all possible outputs it gives). I actually borrowed the methodology from
the "migrate.pl" script that's floating around, but it never worked
correctly and it was easier for me to start from scratch than try to fix it.
And yes, VSS's notion of labels seems to be rather weird; it's like
labeling a file is a separate item in its history, kinda like a commit
without actually changing anything. Plus you can have labels on
projects, and sometimes those get inherited by files in that project and
sometimes they don't. In the end, it's just not worth it to try to
migrate them.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [OT] Re: VSS to SVN migration script
Posted by "Jens B. Jorgensen" <je...@tallan.com>.
Toby Johnson wrote:
>Nathan Kidd wrote:
>
>
>
>>All that info was from a directory's perspective. When doing history
>>on a directory you still get info about the files in it. When doing a
>>
>>
>
>
>
>>single file's history I get the same results as you.
>>
>>BTW, I believe your file-based approach is better. Getting the
>>current directory layout from an SS dir, and then populating with the
>>history of current files is much easier than trying to retrace through
>>
>>
Hey guys! I'm actually the original author (plagiarist? I borrowed
heavily from cvs2svn.py) of vss2svn.py. We took the directory approach
because sadly (at through the automation interface) history on actual
files is incomplete. Believe me, parsing the text of ss.exe was not the
route of choice! I was originally trying to do it through the automation
interface as this is much easier but alas it cannot be done. Here's a
quote from the script:
> # NOTE: originally this script was written to utilize the VSS Automation
> # interface so that all this disgusting parsing of command-line output
> # would not have to be done. Unfortunately, the VSS Automation API
> # is crippled in some dire and more unfortunately, unfixable ways. You
> # can get around some of the issues. Anyhow so the command-line is used
> # to get histories on the files. For a nice in-depth read of what is wrong
> # with VSS (including but not limited to why we must use the command-line
> # tool) read http://www.michaelbolton.net/testing/VSSDefects.html
>>the directory's history.
>>
>>
>>
>OK, I see what you're saying. I believe, though, that the python script
>you refer to tried to build a "dump" file for Subversion to import,
>rather than doing live commits to Subversion in the order they
>originally occured. So that's probably why the other script took the
>directory-based approach.
>
>
yep, exactly. I took that approach basically because that was the
approach cvs2svn.py took and I kinda liked it.
>So, it looks like I still need to account for "branched" and "rolled
>back", no big deal. But Steve had encountered the following output while
>
>running my script, which is completely different than anything I
>encountered:
>
>**********************
>Label: "031013-077p-TY2"
>User: Watsone Date: 13/10/03 Time: 2:03p
>Labeled
>
>***************** Version 1 *****************
>User: Admin Date: 7/10/03 Time: 5:16p
>Created
>
>The separate section about the label is new to me, so I need to see how
>it fits in with everything else.
>
>
It's been a while since I worked on vss2svn.py (and it is by no means
finished in the sense of being fully functional though it does work for
simple cases) I think I remember that VSS doesn't actually associate a
Label with a specific revision, at least not in the sense that it is
attached to it. Cool huh?!
The bottom line with vss2svn.py is that I don't have time to work on it
right now even though I'd love to see it fully working. I would
certainly be willing to spend a little time looking at patches if you
can fix/improve anything in it.
--
Jens B. Jorgensen
jens.jorgensen@tallan.com
"With a focused commitment to our clients and our people, we deliver value through customized technology solutions"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [OT] Re: VSS to SVN migration script
Posted by Toby Johnson <to...@etjohnson.us>.
Nathan Kidd wrote:
> All that info was from a directory's perspective. When doing history
> on a directory you still get info about the files in it. When doing a
> single file's history I get the same results as you.
>
> BTW, I believe your file-based approach is better. Getting the
> current directory layout from an SS dir, and then populating with the
> history of current files is much easier than trying to retrace through
> the directory's history.
>
OK, I see what you're saying. I believe, though, that the python script
you refer to tried to build a "dump" file for Subversion to import,
rather than doing live commits to Subversion in the order they
originally occured. So that's probably why the other script took the
directory-based approach.
So, it looks like I still need to account for "branched" and "rolled
back", no big deal. But Steve had encountered the following output while
running my script, which is completely different than anything I
encountered:
**********************
Label: "031013-077p-TY2"
User: Watsone Date: 13/10/03 Time: 2:03p
Labeled
***************** Version 1 *****************
User: Admin Date: 7/10/03 Time: 5:16p
Created
The separate section about the label is new to me, so I need to see how
it fits in with everything else.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [OT] Re: VSS to SVN migration script
Posted by Nathan Kidd <na...@hummingbird.com>.
Toby Johnson wrote:
>> +# Types of ss history output lines for a file object's data:
>> +#-----------------------------------------------------------
>> +
>> +#***** FileName.ext ***** ; first line
>> +#Version 229 ; revision number
> What I
> don't understand, though, is the lines with the filename embedded within
> the asterisks. Do you get this sort of output when viewing the history
> on only one file at a time (which is what my script does)? I had only
> ever seen the *version number* in the asterisks line.
All that info was from a directory's perspective. When doing history on
a directory you still get info about the files in it. When doing a
single file's history I get the same results as you.
BTW, I believe your file-based approach is better. Getting the current
directory layout from an SS dir, and then populating with the history of
current files is much easier than trying to retrace through the
directory's history.
> It would still probably help if I could see the entire output from a "ss
> HISTORY" command of a single file which has file labels, inherited
> parent directory labels, branches, and whatever else is possible. It
> helps to see not only what can be output, but the order I can expect
> them to appear in.
I think you'll find the order and syntax the same as what I documented,
except for the difference in the first couple lines. But don't just
look at the things I listed for "file object's data". The "output lines
for a directory" don't only talk about directories; they include the
history of *files* in the directory. The division is there only because
of parsing difference in the first few lines, not because one is about
directories and the other files.
-Nathan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [OT] Re: VSS to SVN migration script
Posted by Toby Johnson <to...@etjohnson.us>.
Nathan Kidd wrote:
> This can be solved by using ss.exe's -o@ option to output to a file
> and then read the data from the file. No hard wrapping occurs. This
> is particularly important not just for comments: if you have really
> long paths in VSS they also will be hard-wrapped! Attached is my patch
> for vss2svn.py to do this. (vss2svn.py.patch.nohardwrap)
> ...
>
>+# Types of ss history output lines for a file object's data:
>+#-----------------------------------------------------------
>+
>+#***** FileName.ext ***** ; first line
>+#Version 229 ; revision number
>+#User: username Date: 3/12/02 Time: 3:48p ; info line, in every rev.
>+#Checked in $/basedir ;
>+#Branched ; file dup of dir rev message
>+#Rolled back ; ignore, history was purged
>+#Comment: -item 1 fixed ; always last, CR/LF not
>+#-item 2 fixed ; escaped: keep reading lines
>+
>
>
Thanks a lot Nathan, this should be a help for me. I didn't know about
the -o@ VSS option either, but heck, why not slow down the script even
more by writing all history output to a file? :) It'd be worth it to me
though not to introduce all those line breaks.
I'm not too interested in directory history comments since I just import
the entire directory structure to begin with. I can probably just ignore
the branch stuff, but the label stuff might be sorta tricky. What I
don't understand, though, is the lines with the filename embedded within
the asterisks. Do you get this sort of output when viewing the history
on only one file at a time (which is what my script does)? I had only
ever seen the *version number* in the asterisks line.
It would still probably help if I could see the entire output from a "ss
HISTORY" command of a single file which has file labels, inherited
parent directory labels, branches, and whatever else is possible. It
helps to see not only what can be output, but the order I can expect
them to appear in.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org