On 6/2/06, Dirk <[EMAIL PROTECTED]> wrote:
Jon W schrieb:
> Hi Dirk. Good news, your latest changes really cleaned up a bunch of
> problems.
>
> One problem that is noticable now is that some files are having issues
> with the following scenario.
>
> /Project/Source/Sim/PropRec.h created on 09/30/04
>
> /Project/Wiz/Sock/Source/PropRec.h shared from
> /Project/Source/Sim/PropRec.h on 10/04/04
>
> /Project/sock/sdk/incl/server/PropRec.h shared from
> /Project/Wiz/Sock/Source/PropRec.h on 9/7/05
>
>
> /Project/Source/Sim/PropRec.h deleted on 12/05/05
>
> /Project/Wiz/Sock deleted on 12/13/05
>
> /Project/sock/sdk/incl/server/PropRec.h checked-in version 4
>
> /Project/Wiz/Sock recovered on 01/24/06
>
> The issue is that /Project/Wiz/Sock//Source/PropRec.h file is still
> at version 3 in the svn repo. I wonder if this has to do with how the
> file was shared between 3 directories, then some of the shared
> files/directories were deleted.
If you had deleted the /Project/Wiz/Sock/Source/PropRec.h on 12/13/05
everything would have been fine ;-)
The problem is, that the recovery of project will recover the project to
state of the project one revision before the deletion. Our code does not
handle situations, where a shared file was modified through a share,
while one of the parent projects was in a deleted state. Since
subversion doesn't know the concept of sharing, there is also no way to
perform commits to the deleted directory. Even worse, I expect, that you
also can rename files via shares in the same way. In order to solve
this, we must capture all modifications on the files during the deleted
state and perform the modifications, after the project has been
recovered. ... Another alternative is to not delete projects in
subversion, but to move them into an "attic" area. The we can continue
to commit to the deleted files and if we recover, we move them out of
the "attic" again.
Actually I consider this feature of VSS as very problematic. Same is for
renaming of shared files. These two issues are two of the main reasons I
want to move away from VSS.
Is this of a major impact for you, or is this only a "costmetic" issue,
since the converted project does not precicly match the state of the
archive?
Hi Dirk.
I'm not really sure how big of an issue this is at first glance. It
won't be a big issue if the share/delete/recover action happened
within a short period of time, as then maybe only one or two revisions
would be missing, and I could add them to each file by hand. The
problem would be with a delete/recover happened over a timeframe of a
year or so with many changes involved. I will say that this doesn't
appear to be a large problem for me at first glance, although I'll
keep looking.
If I had to choose issues at the moment, I would be more interested in
saving the file history from the other email "pin_handler: file
history issue move/share/delete" scenario.
I'll keep looking. Trying to figure out what vss actions happened,
and how/why developers did what they did, and how it all got
translated in the svn conversion can be a bit maddening sometimes. :)
Thanks,
Jon
_______________________________________________
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
