Jon W schrieb:
On 5/4/06, Dirk <[EMAIL PROTECTED]> wrote:
> **** NEW SVN REVISION (0): AAAAAAAA,776460713,Admin,
> ADD: AAAAAAAA, @ 776460713
> _get_item_paths(AAAAAAAA)
>
> **** NEW SVN REVISION (1)ERROR -- Attempt to add entry 'NFAAAAAA' with
> unknown parent
I'm a little bit astonished about the order how things are happening
here: The point is, that the names of the phyiscal files are used in a
increasing order, so the first file is AAAAAAAA, the second one
BAAAAAAA, the third one CAAAAAAA, and so on. During the conversion the
files should appear in the same order. So revision 0 is AAAAAAAA,
revision 1 is BAAAAAAA, revision n (n>1) is CAAAAAAA and so on. If you
later destroy BAAAAAAA, we wont see it in the conversion process, but
still the order when the files will appear the first time would be
increasing.
What we see here, is that in revision 1 the file NFAAAAAA was added to
the project AAAAAAAA. But the file BAAAAAAA comes later. The only way
that this can happen is a bulk checkin, where a complete directory was
added. But in this case the file BAAAAAAA is the directory and all the
other ones are subdirs. So I still would expect to see BAAAAAAA to come
first. strange
Later we will see the addition of the project FAAAAAA which is inbetween
BAAAAAAA and NFAAAAAA. So this first revision couldn't be a bulk checkin
of 1000 of files.
The only idea I have about this is a broken timestamp. Do you have used
archive and restore cycles?
Dirk
That is possible, as the database is 12 years old. I heard that a few
years ago the database got in a bad state, and some special tools from
microsoft were used to fix the problem after a call to support.
Any ideas of what can be done?
Could you please try to lookup up all traces of NFAAAAAA in
physicalAction dumpfile?
The file NFAAAAAA should have at least one parent. You could try a
ssphys info NFAAAAAA > NFAAAAAA.xml also to check for the parent
projects. Please lookup up all parents until you reach the root project.
Also a dump of the root project would be very helpful: "ssphys info
AAAAAAAA > AAAAAAAA.xml"
And finally have a look at the phyiscalAction datacache around line 4
and 5. You should find problematic delete and rename actions here.
Please lookup the items and item names on which these actions happen.
Also check the timestamps, whether they are increasing for each version
of the root project.
You can send me the files privatly if you are afraid of publishing
protected information.
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
