Hello Ingo,
thanks for using vss2svn and good to hear, that it was of a benefit for
you. I'm interesting to see your script.
Regarding your modification this is a little problematic and you also
touched the problem yourself. We choosed to use the physical file name
as the orphaned name, since this is the only unique name. Look into your
script and you see, that you mapped two different physical files to the
same path:
+"_JLBAAAAA" => "/high-hopes/docs/",
+"_ZKBAAAAA" => "/high-hopes/docs/",
This can wok, but this can also fail. The phyiscal id is the only unique
key to identify items. The real name itself can change over time and
could also be different in various contexts. If you map two physical
items to the same path, the detection and tracking logic can fail to
find the correct copy-from pathes.
Technically there are the folowing reasons why you get orphaned files:
1.) The insane Archive Restore Handling. But with the latest script this
should move all files out of the orphand cache at the time of the
Restore. So in the end you don't see any files in the orphaned directory
anymore
2.) real orphaned file: Files that left over, because their parent
projects have been deleted and there is no more reference to them.
Ideally a analyze -d should delete those files
3.) a broken archive, but then the detection of the real name is also
very problematic
I for myself have 5 orphaned files left over and I know, that these
files are not used anywhere in the context of the remaining projects.
They simply fail to clean from the database, probably because there is
still a reference count on them.
So I would ask you to try the latests nightly build and see, whether you
still have orphanes. If this is the case, try the "-d" flag on analyze.
If there are still orphanes, we should try to figure out the reason, and
whether the files should be actually there.
But getting the "real" path automatically is difficult. That is the
reason, why the files are oprhaned, beacause they don't have a real path.
Best regards
Dirk
Ingo Schmidt schrieb:
Hi everyone!
Last month I had to convert a VSS database to Subversion using
vss2svn. Since vss2svn is not able to extract single projects into a
dumpfile, I had to do this myself.
I ended up writing a bash script for that and I am going to make this
publicly available.
With that script you can do a fully automated conversion and splitting
of the big dumpfile created by vss2svn into single repositories.
You just specify a few things, like projects to keep and destroy and
also some dependencies.
The script then handles the rest for you and you can go to sleep and
have the result the next day.
But before this goes public, I wanted to hear your opinion about a
feature that I hacked into ActionHandler.pm for my needs. Beware, it
is the first time ever that I touched perl code. I didn't even read
any docs. However, the change is extremely simple, but effective. See
attached diff file.
%orphanedReplace just has some demo entries in this diff file. The
list was certainly 20 times as long.
The purpose of this modification is to give all these "orphaned"
folders a real name - their actual names how they were back then. I
had put a lot of energy in finding out the real names. Using the VSS
history I actually did manage to find all the real names.
I am dead sure that there is a much better way of having this feature
in vss2svn, like reading the orphaned<->realname pairs from some file.
But I have no idea how to do this, since I have no real knowledge of
perl.
What do you think of this feature? Could somebody with more perl
knowledge than me maybe program such a feature in a better way than I
did?
This would be great and it would also simplify the use of my script a
great deal.
Cheers, Ingo =;->
------------------------------------------------------------------------
_______________________________________________
vss2svn-users mailing list
Project homepage:
http://www.pumacode.org/projects/vss2svn/
Subscribe/Unsubscribe/Admin:
http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org
Mailing list web interface (with searchable archives):
http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user
_______________________________________________
vss2svn-users mailing list
Project homepage:
http://www.pumacode.org/projects/vss2svn/
Subscribe/Unsubscribe/Admin:
http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org
Mailing list web interface (with searchable archives):
http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user
