Jon W schrieb:
On 5/11/06, Dirk <[EMAIL PROTECTED]> wrote:
>
> I should have been a bit clearer. Here is the basic order:
>
> $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
> $Source 06/06/01 3:00pm Destroyed
I did understand it this way. And my explanations cover exact this
situation, but I think I have to be more precise on the reasons:
VSS will store all structure related activities within the "project"
items and all content related changes within "file" items. Both types of
files are managed the same way in a physical file with a specific binary
layout. For "file" items, the physical file will record all changes and
the corresponding .A or .B file will contain the tip version of the
file. For "project" items again the physical file records all changes,
and the .A or .B file records the layout of the last state of the
project. E.g. it will record, that the project contained two files and 3
deleted ones.
If you destroy an item, the physical file and the .A/.B file are wiped
away from your hard disc. There is now chance to reconstruct any history
of this item any more. If you destroy a project, there is no chance to
know how the project was structured at a specific time.
Since the project must have been added to another project, there is
still the information, that there was a project of the specific name,
but no chance to get to the layout anymore.
Since the history of an item is stored in one physical file and a share
operation is more or less only increasing the refcount to this file
(together with the bookkeeping information) you are still capable of
getting to the history of the file before the main parent was destroyed.
This is due to the fact, that VSS is item based. This is also the
reason, why the ssphys program can reconstruct each version of an item
only based on the two files. All files are glued together to form an
archive by the information recorded in the file. But the history of each
item is recorded only with the item.
During the conversion we extract the "glue" between the items and try to
reconstruct the history. From the parent of $Project we know that there
was a project of the name $Project, but due to the fact, that the
$Project project was destroyed, we do not know how the project looked
like.
Later we will see creations and modifications on files but we don't know
that these files belong to the $Project, since the glue between the
$Project and the file item is missing. So we can't convert these
actions.
Now you rename $Project to $Source. No problem here, but the project is
still empty, since we don't know what happened in the mean time.
You create a new project $Project. This time we will have the glue,
since this project is still alive
You share files from $Source to $Project. The glue will tell us, the the
files were shared from the destroyed project $Source, but since we
couldn't track the addition to the destroyed project, we can't copy from
the destroyed project. We must fallback to an add with the content at
the time of the share.
The only way to solve this is a lost+found directory, where we save all
modifications that doesn't have a parent anymore at the time of the
modifications.
You can try yourself extracting your state of the $Project directory
prior to the mystic date 05/04/01, e.g. with a recursive checkout at a
specific a date. You will see, that you can't checkout the project
$Project, since it doesn't exists anymore. VSS will fail to give you
your files.
You can go to each file and extract prior versions of the file on a per
file basis, but not as a whole of the complete archive.
subversion is different. The versioning is done on the complete
repository and not on each file separately. In complete contrast to VSS,
each revision is stored in a unique file. This will give you features,
like atomic commits and per repository revision numbers, but you will
loose the ability to extract a version of a file prior to the date the
parent project existed.
Again, since you destroyed the project, you destroyed the glue between
your projects and items in your archive. You didn't destroyed the
history of the items. Only the glue between them. And since the glue is
missing between 1997 and 05/04/01 we can not track the modifications of
the files.
I hope this made it a little clearer.
Things are a bit clearer, thanks. The new conversion tools just act
differently from the legacy vss2svn conversion script, as that saved
all of the file history (although it had many other problems with a
database as old and large and odd as mine). Of course that used
ss.exe, was 100X slower, etc.
Yes, but I expect, that the conversion of your archive with the old
converter only worked by accident. The reason is that you used the same
name for your newly added project than the one from the destroyed project.
The biggest problem of the old ss.exe based script was, that the path
lookup of an item is done in the latest version. That is in your case,
if you do a "ss history -v31.03.2005 $Project/file.txt" prior to the
05/04/01, the path is looked up in the jungest version and then the
history of this item is displayed. Only by accident your "file.txt" item
is the same item than the $Project/file.txt item that existed prior to
05/04/01 due to the fact that you shared the items.
But consider the following situation in pseudo vss code:
1: ss create $/Project1 --> phyiscal id baaaaaaa
2: ss create $/Project2 --> phyiscal id caaaaaaa
3: ss add $/Project1/file.txt --> physical id daaaaaaa
4: ss add $/Project2/file.txt --> physical id eaaaaaaa
5: ss destroy $/Project1
6: ss rename $/Project1 $/Project2
You see, that I have two different files "file.txt" that do not share
the same history. The files are stored in a different phyiscal file. In
step 5 and 6 I have destroyed the first project and renamed the second
project to carry the same name as the first one.
If you perform a lookup of the item $/Project1/file.txt after step 6 you
will get the history of the phyiscal file eaaaaaaa. BUT even if you
specify a version prior of step 6 on the command line you will ALWAYS
get the history of the item eaaaaaaa and never from daaaaaaa. You have
to use a still vivid item path of the the phyiscal file daaaaaaa in the
latest tip, so that you can see the history of the file.
In this case, the old converter would have simply picked the history of
a wrong file and the coversion was successfull but erroneous.
I tried hard to circumvent this effect, esp. I tried the OLE API tools
of VSS. But they were broken in another sence, so I finally wrote my own
converter.
I have another problem with the following situation, that when loading
the dumpfile it exits saying that the directory was already added:
<<< Started new transaction, based on original revision 33973
svnadmin: File already exists: filesystem 'repo/db', transaction
'33972-1', path 'Project/Source/Horse'
* adding path : Project/Source/Horse ...
Looking through the VSS history, it appears as though something
similar to the following happened:
--------------------------------------------------------------------------
$Project/Source
$Horse 12/17/03 11:45a Added
foo.cpp 12/17/03 3:02p Created
$Horse 10/15/04 11:04a Moved to
$/Project/Transportation/Horse
Yes, move to is not supported yet in the pin_handler branch. The reason is
1.) I was lazy and didn't used the MOVE action. So I had no need to fix it
2.) There is a problem with the logic vss2svn is working. As I mentioned
above the glue between the items is only that tow items mention themself
as beeing a parent or a child of each other. If you add an item to a
project. the item will remember, that it was added to the parent and the
parent will record, that the item was added. So we will see two records
about the action. Sincerelly we can not simply drop one of the records,
since we need information from both records to build up our own history.
This is done in the MergeParentData step. Here all information from the
parent and the child records are merged together.
For the MOVE action there is something similiar. The MoveFrom record
doesn't record the physical file the item was moved to and vice versa
the MoveTo record doesn't record the move source. So we need them both
to now the source and the target of the move operation. Since the moving
is not done between parents and child, but between two parents, these
records are not picked up by the MergeParentData step. So I need to
write a seperate logic to merge move actions.
This is not compilcated, but must be done in order to support moves.
Currently I have no real workaround for this, except you "destroy" the
moved project on your local test archive. But be really careful that you
work on a test archive.
I will dig into these problems as soon as I have some more time again,
hopefully next week.
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
