The vss action was a delete (followed by a destroy a few months later), and the svn action used was an "add" on 05/04/01 for both the directory and files.
Just let me know if you can think of anything that I should try or lookup. I'll keep looking in the meantime. Thanks, Jon On 5/11/06, Dirk <[EMAIL PROTECTED]> wrote:
Jon W schrieb: > So far the pin_handler branch is working relatively well for the > conversion, but I am hitting a problem. (The beta version didn't > handle several renames properly, so I had to use the pin_handler > branch.) Please keep in mind that a few exotic actions are not corrently working in this branch, esp. move, archive, restore The other ones need some further testing, whether they are all handled correctly. > The repository started around 1994, and on 05/04/2001 the following > happened that causes a import to only see the history from 05/04/2001 > (i.e. svn creation date). > > Note: $Project is the working directory for development.. > > $Source 05/04/01 12:44pm Renamed $Project to $Source > $Project 05/04/01 1:08pm Added > [ Shared files in $Source to $Project ] > $Source 05/04/01 2:06pm Deleted > > Between the 1:08pm ---> 2:08pm timeframe, files that were in $Source > (the previous $Project that was renamed) were shared into the newly > added $Project. In VSS, this allows the file to still see the history > since the real creation of each file. However, in the svn converted > repository, all files and directories are created on 05/04/01. It is > true that the directories were created on 05/04/01 in vss, but the > files were actually created much earlier due to the shares. subversion doesn't know the concept of sharing, so a share is mapped to a copy. Also subversion does not yet support nativ renames. A rename is actually implemented via a delete and a copy-from cycle. I'm not fully sure, but when displaying the history in subversion the log stops at a "copy-from" action. At least in in TortoiseSVN e.g. you can set an option, whether you want to follow a Copy or Rename action. In the pin-handler branch a renames and shares are mapped to the corresponding subversion actions everytime, only when we have a copy-from revision. This is due to the fact, that a copy-from action msut explicitly specify the correct path and revision to copy from. When renames are involved things can get dirty. The converter tries to track the state of the archive for all revisions. But if it can't find a copy-from revision (e.g. due to a destroyed parent folder) it falls back to an add action. Please note the difference of destroy and delete. A delete can be tracked since the files are still available. A destroy is lost. E.g. if you had destroyed the $Source folder you have destroyed the complete knowledge about the layout of your archive at times earlier than 05/04/01. We and vss have no way to restore the state of the archive earlier than 05/04/01 since we don't know that you ever had added a file to the archive. The fact, that the file has a history earlier than 05/04/01 is useless in this respect, since it hasn't had a parent. The file is dangling around. What we can do within the converter is that we map all these files into a lost+found directory. But here we have the problem of uniqueness of the name. E.g. what happens if you have two files with the same name that existed in two different projects which where destroyed? So actually your described szenario should work (if it really was a delete). Please try to lookup in your newly repository, what caused the file creation at 05/04/01. Was it really an add or was it a Copy-from? If it was really an add, we must figure out, why the converter didn't found the revision to copy from. This is a little complicated, since I don't know of a way to lookup this information from the dump files. All this is encoded in the internal maps of the converter. I currently have no idea how to find the reason for this, except dumping the internal maps at a specific revision. I will try to reproduce your described szenario in a test case. Then things will be easier. If you can use a perl debugger, it would be even better ;-) Best regards 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
_______________________________________________ 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
