Hi, I just wanted to say thanks for all the information you all gave on label support. Subversion is cool as hell and the community is very helpful. I appreciate your help very much.
Sincerely, Adam -----Original Message----- From: Dirk [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 02, 2006 2:30 AM To: Vss2Svn Users Subject: Re: Label support 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 *********************** Confidentiality notice: This electronic transmission message is intended only for the use of the individual or entity to whom it is addressed. This information should be treated as proprietary, confidential, legally privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, (or the employee or agent responsible for delivering the message to the intended recipient), you are hereby notified that any use, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please immediately notify us by telephone (720) 221-9421 or by return e-mail and delete this message. Thank you for your cooperation. _______________________________________________ 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
