dumpfile errors when loading

2006-05-03 Thread Jon W
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.

Re: dumpfile errors when loading

2006-05-03 Thread Jon W
[ 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

Re: dumpfile errors when loading

2006-05-04 Thread Jon W
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

Re: dumpfile errors when loading

2006-05-04 Thread Jon W
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

pin_handler: rename/add/share/delete

2006-05-10 Thread Jon W
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

Re: pin_handler: rename/add/share/delete

2006-05-11 Thread Jon W
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.)

Re: pin_handler: rename/add/share/delete

2006-05-11 Thread Jon W
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

Re: pin_handler: rename/add/share/delete

2006-05-11 Thread Jon W
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

Re: svnload: File already exists

2006-05-19 Thread Jon W
<<< 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

Re: pin_handler: rename/add/share/delete

2006-05-22 Thread Jon W
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

Re: pin_handler: rename/add/share/delete

2006-05-22 Thread Jon W
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

Re: pin_handler: rename/add/share/delete

2006-05-23 Thread Jon W
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

Re: pin_handler: rename/add/share/delete

2006-05-25 Thread Jon W
>> 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

Re: pin_handler: rename/add/share/delete

2006-05-26 Thread Jon W
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

Re: refactored sanity checker with label handling in the pin_handler branch

2006-05-30 Thread Jon W
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

Re: refactored sanity checker with label handling in the pin_handler branch

2006-05-31 Thread Jon W
> 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

Re: refactored sanity checker with label handling in the pin_handler branch

2006-05-31 Thread Jon W
> 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

Re: refactored sanity checker with label handling in the pin_handler branch

2006-06-01 Thread Jon W
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/

pin_handler: file history issue move/share/delete

2006-06-01 Thread Jon W
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 "

Re: pin_handler: file history issue move/share/delete

2006-06-02 Thread Jon W
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

Re: pin_handler: file history issue move/share/delete

2006-06-02 Thread Jon W
> > 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

Re: refactored sanity checker with label handling in the pin_handler branch

2006-06-02 Thread Jon W
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

Re: pin_handler: file history issue move/share/delete

2006-06-02 Thread Jon W
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

Re: pin_handler: file history issue move/share/delete

2006-06-02 Thread Jon W
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

Re: FWIW, my patch for 0.10 Beta 2... done on FC4

2006-06-05 Thread Jon W
> 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

rollback action causing problems?

2006-06-08 Thread Jon W
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

Re: rollback action causing problems?

2006-06-08 Thread Jon W
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

Re: rollback action causing problems?

2006-06-12 Thread Jon W
> >> 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

timestamp issue?

2006-06-12 Thread Jon W
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

archive and restore risks

2006-09-20 Thread Jon W
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