When using the beta2 conversion tools, I was able to create a
dumpfile; however, the dumpfile has several problems when loading.
The first failure was:
==
<<< Started new transaction, based on original revision 5
* adding path : IDEFiles ...COPIED... done.
[ comments inline]
> When using the beta2 conversion tools, I was able to create a
> dumpfile; however, the dumpfile has several problems when loading.
>
> The first failure was:
> ==
> <<< Started new transaction, based on original revision 5
> * adding
On 5/3/06, Toby Johnson <[EMAIL PROTECTED]> wrote:
Jon W wrote:
> It doesn't appear as thought the root path was really deleted. When
> looking at the VSS history of $/, the following happened:
>
> Created
> $FirstProject Added
> $WholeIDE Ad
On 5/4/06, Dirk <[EMAIL PROTECTED]> wrote:
> NEW SVN REVISION (0): ,776460713,Admin,
> ADD: , @ 776460713
> _get_item_paths()
>
> NEW SVN REVISION (1)ERROR -- Attempt to add entry 'NFAA' with
> unknown parent
I'm a little bit astonished about the order how
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.)
The repository started around 1994, and on 05/04/2001 the following
happened that causes a i
n 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.)
On 5/11/06, Dirk <[EMAIL PROTECTED]> wrote:
Jon W schrieb:
> 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 o
On 5/11/06, Dirk <[EMAIL PROTECTED]> wrote:
>
> I should have been a bit clearer. Here is the basic order:
>
> $Source05/04/01 12:44pm Renamed $Project to $Source
> $Project05/04/01 1:08pm Added
> [ Shared files in $Source to $Project ]
> $Source05/04/01 2:06pm Deleted
> $Sour
<<< New transaction based on version 26 started
* Adding path: ...svnadmin: File already exists: File system 'D:/
Repositories/SVN/db', Transaction '25-1', Path ''
Look at the datacache.VssAction.tmp.txt and
datacache.PhysicalAction.tmp.txt files to see the ordering of the
actions. Look
Thanks for the update Dirk. I reran the conversion with the
--task=IMPORTSVN option, and when loading the dumpfile, it failed as
follows:
<<< Started new transaction, based on original revision 33423
* deleting path : Project/Source/Sim/foo.h ... done.
svnadmin: File not found: revision 3338
I was just testing my modification and came across another issue with
the sanity checker (see my other mail) Could you please try to uncomment
the following lines in the Dumpfile.pm:
#($this_action, $itempath) =
#$self->_action_path_sanity_check($this_action,
$itempath
Thanks for the notice. I killed the conversion that was in the
process of creating the dumpfile, and updated. With the changes you
made, should I start the conversion from scratch, or use the --resume
--task=INIT ?
Guess that I'm still not sure when it is necessary to start everything
from scra
>> I just have reverted the delete/recover handling to the algorithm
>> used in the beta-2 version. This is that the deleted items are
>> tracked seperately. If you want to help, you can test the latest
>> revision. I have not done intensive testing with my archive. So be
>> aware, it could brake
On 5/26/06, Dirk <[EMAIL PROTECTED]> wrote:
> Just fyi - After I sent you the email, I updated and restarted the
> conversion. I should have some more info for you at the end of the
> day.
There is a small race condition between two issues in the latest
version: If you have assigned a file lab
On 5/29/06, Dirk <[EMAIL PROTECTED]> wrote:
Hi Jon, hi Kenneth,
I have refactored the sanity checker in the pin handler branch, and the
dumpfile finally loaded with my archive including Label support. Your
mileage may vary, but I would suggest to perform any further testing
with this code, since
> The first is related to how the $Project was
> renamed/added/deleted/destroyed in 2001, from which that is the date
> that the svn converted repo starts:
>
> $Source05/04/01 12:44pm Renamed $Project to $Source
> $Project05/04/01 1:08pm Added
> [ Shared files in $Source to $Project
> Just to let you know, there was a typo in the Dumpfile.pm changes.
> Line 463 should be changed from:
>if (!defined ($data->{version}) {
> to:
>if (!defined ($data->{version})) {
Hi Dirk. Do the Dumpfile.pm changes need to be committed?
I'm a little astonished, since resuming from B
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/
I'm using the pin_handler branch at rev 236 (the latest rev as of 06/01/06).
The issue is as follows:
-
Project/Source/Solver created on 10/07/03
[ several files are created and modified ]
Project/Source/Solver is "
On 6/2/06, Dirk <[EMAIL PROTECTED]> wrote:
Jon W schrieb:
> I'm using the pin_handler branch at rev 236 (the latest rev as of
> 06/01/06).
>
> The issue is as follows:
>
-
>
> Projec
>
> Within the svn converted repo at Project/sock/dir/solver_dir most of
> the files only have revision history starting on 09/08/05 when the
> solver_dir was created. Note that the files were actually shared on
> 09/09/05.
Just a dump question? Are you checking with TortoiseSVN? there is a
"stop
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/S
On 6/2/06, Dirk <[EMAIL PROTECTED]> wrote:
Jon W schrieb:
>> >
>> > Within the svn converted repo at Project/sock/dir/solver_dir most of
>> > the files only have revision history starting on 09/08/05 when the
>> > solver_dir was created. Note that the f
On 6/2/06, Dirk <[EMAIL PROTECTED]> wrote:
>
>
> When looking at the VSS database, the file foo.cpp version information
> is as follows:
> v15 Bob Checked in $/Project/Wiz/Solver
> v14 Bob Checked in $/Project/Wiz/Solver
> v13 Bob Checked in $/Project/Source/Solver
> v12 Bob Chec
> Largest dumpfile so far. Looks promising... but:
> svnadmin: Malformed dumpstream: Revision 0 must not contain node records
I expected that there is a problem with revision 0 ;-)
I don't understand why this worked for me.
Could you please the latest revision? The conversion now simply starts
a
The revision 245 of the pin_handler branch is working great at first
glance. In fact, now we have history of the files all of the way back
to 1997. The original directory may be orphaned, but at least the
file history and diffs are available.
One issue that I'm noticing is that several files do
Hi Dirk.
So actually Branching and RollBack is the same. The BranchFile is the
parents view and the RollBack is the childs view of the branch action.
I hoped that this "HASH(0xc428a34)" kind of errors silently went away.
But it seems, that this is the root of the problem. I have no idea,
where
> >> What about the following code?
> >> > $tphysname = $action->{Physical};
> >> > if (!defined ($action->{Physical}) || (ref($ref) eq 'HASH')) {
> >> > $tphysname = $physname;
Hi Dirk. This code change fixed the "HASH" problem, and those files
are now importing with history starting at
I have a few files that aren't being converted properly. Of such
files, the full history is available in the orphaned directory. Is
this a case of the timestamp being off?
$ grep element.cpp datachache.PhysicalAction.tmp.txt
133590 WNQD1 \N ADD element.cpp 2
I have a large vss database to convert, and have been doing the following:
-Purging all of the vss deleted files.
-Destroying unwanted directories/files
-Archiving the desired top level directory
-Restoring the archive into a new vss db.
-Running the conversion from the "trunk"
This all appears
30 matches
Mail list logo