Hi,
I noticed that the RESTORE action had made the MOVE into the
pin_handler. I suspect there is a problem in that implementation,
since all orphaned files and folders end up in the same folder. At
least my load operation broke in svnadmin. If there are two files with
identical names in two restored folders, their history will get mixed
up, and after the first file is MOVED into position, the second MOVE
will break (as there is no longer a file in svn in that folder with
that name).
You are completely right on this. Since this was my first attempt to
enable the RESTORE action, which was actually triggered by your patch. I
took the easy route to give it a first try. I have currently two
solutions in my mind how to fix the problem:
1.) mangle the files added to the orphaned directory with the physical
ID: This would be ok as long as renames would work only locally. But
actually renames work on all shares. And if a file in the orphaned cache
is renamed through a share we are in trouble again.
2.) insert another dummy parent with the name of the physical file to
the orphaned directory structure. In this case we will have a unique
space for each orphaned file, and won't have any problems, except that
we must generate a complexer algorithm to introduce this dummy project.
(While writing these lines, I had an idea of an easy solution for this.
Currently I'm using "99999999" as the physical id for the dummy project.
Since we are not dependent on the length of the physical ID, I could use
the id of the orphaned physical file together with a magic marker for
orphaned files. In case someone is asking for the item path of such an
item, we would stop at the magic marker and return a complex directory,
containing the orphaned folder and the physical name of the orphaned
file, here. All missing directory creates are picked up by the sanity
checker, so there shouldn't be any problem. I will give this a try
directly.)
My patched turned the last character into a Z for the id of the parent
folders for the orphan items. Going beyond the eighth character boundary
seems like a neater trick.
I hoped for the beginning, that nobody had two equally named orphaned
files ;-)
Reality is always more strange that one can possibly imagine...
I encountered a problem when a folder and a file in that folder was
created in the same second. In the resulting output, the file was added
before the folder was created. (fixed in the patch)
Completely unrelated question: how does SourceSafe handle a repository
in a shared folder when two accessing workstations have misaligned
clocks? If A's clock is an hour ahead of B's and A commits before B.
Is the history correct as commited, or are the entries sorted, or is
the error detected before the commit?
Puhh, good question. As long as the two modifications on the repository
are disjunct, I would expect, that VSS doesn't detect the situation. A
and B would modify the archive with it's own misaligned timestamps and
we would have a somehow chronological wrong history.
If both workstations would modify the same file or project, I'm not
sure, whether VSS will print any warning message. In would expect again,
that this sort of error isn't covered correctly. Probably the analyze
would figure it out and correct the timestamps, so that they are at
least chronological.
Currently we are using the timestamp as the one and only source of
information to figure out the the history of events. If two timestamps
are identical, we have a specific priority. I expect, that we could do
better, if we follow the creation of projects and the commits of
changes. So it would be an error to have an earlier timestamp on greater
version. Currently we haven't had any problem due to this fact, so we
didn't focused on this. The only problematic area currently is the safe
detection of the CREATE and ADD actions, that is an item is created and
the item is added to the parent project. If you have a slow network
connection, these two times can vary up to 25 seconds in my archive. I
expect to see even grater delays here. So improving this logic would
help again for a correct conversion.
>
Additionally there is the request to only convert parts of the archive.
This would imply, that we build our data structures on the fly, which is
not possible right now.
Is that to improve speed or reduce output? One could filter afterwards.
And Perl seems to be such a nice language for filtering stuff. Perhaps
you can identify some points in the script where one could insert a
modular filter.
Cheers,
/Micke
_______________________________________________
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
