Thank you Paul, for the precise description.
Dirk, I'm curious if you considered inverting the structure, like
labels/
Project1/
1.0/
2.0/
Project2/
1.0/
2.0/
2.1/
and determined this layout to have problems.
I thought about this, yes. I did it first the other way to learn about
the label handling support in vss, and to get a solution up and running.
The problem with your above suggestion is
* "label promotion"
* "version label vs. item label".
In a "label promotion" szenario you assign a label to a project and
later you assign the same label to a file deeper in the project
structure. When you checkout by label you will get the state of the
project at the the time of the label, but for the file, you get the
later one.
The labeling activity is an activity by itself. It is a distinct version
record, that we can handle within in vss2svn.
Additionally you can attach a label to every version of an item itself.
In this case the label is stored within the version record of another
version. I haven't checked, but I think these labels take place in label
promotion also.
Now comes the difficult part. There is no reason, why label promotion
don't work backwards. So you can assign a label to a version of a file
prior to the time the label was assign to one of its parent projects.
Now we are in trouble, since we will see the version label first and
need to decide that this belongs to a specific project.
Be aware that the Subversion repository can end up with nested
'labels' directories. This happens if the root of the VSS database
was labeled.
$/ (labeled '1.0')
then later
$/ (labeled '2.0')
These labels are converted to
labels/
1.0/
2.0/
labels/ (this directory is unexpected)
1.0/
This is right also. The problem is, that the vss database is imported
into the root space of the subversion repository, the same place where
the labels and all other organisational directories live. I thought
about introducing a new layer, like "import" only for the import, so
that this can be solved easily.
The conversion of the database is not perfect. My primary goal is to get
all information converted, so that one can adjust the data after it is
converted in vss. I don't want to build the perfect conversion. I think
it is better to clean up the data in subversion later.
Dirk
_______________________________________________
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
