nandinicvs | 22 Apr 14:37

error while creating repository from dumpfile


hi all,
I have created the dumpfile for my repository ...and then used svnadmin load
to create the repository out of the dumpfile.....I got the following
error....
<<< Started new transaction, based on original revision 6345
     * adding path : orphaned/_YGFBAAAA ... done.
     * adding path : orphaned/_YGFBAAAA/Report ... done.
     * adding path : orphaned/_ZHFBAAAA ... done.
     * adding path : orphaned/_ZHFBAAAA/ ... done.
     * adding path : orphaned/_NIFBAAAA ... done.
     * adding path : orphaned/_NIFBAAAA/App_ces ... done.
     * adding path : orphaned/_NJFBAAAA ... done.
     * adding path : orphaned/_NJFBAAAA/Service ... done.
     * adding path : orphaned/_RJFBAAAA ... done.
     * adding path : orphaned/_RJFBAAAA/Service ... done.
     * adding path : orphaned/_SJFBAAAA ... done.
     * adding path : orphaned/_SJFBAAAA/rService ... done.
     * adding path : orphaned/_WJFBAAAA ... done.
     * adding path : orphaned/_WJFBAAAA/Service ... done.
     * adding path : orphaned/_WJFBAAAA/M.....ade.d
iscomap ...svnadmin: File not found: revision 5831, path
'/orphaned/_UDBBAAAA/..///....sie.discomap'

any reasons why could this be and how to solve this????
Thank u in advance.....
--

-- 
View this message in context: http://www.nabble.com/error-while-creating-repository-from-dumpfile-tp16823841p16823841.html
Sent from the vss2svn - users mailing list archive at Nabble.com.

(Continue reading)

Bryan Aldrich | 22 Apr 15:06

Re: error while creating repository from dumpfile

I also had this in very large quantities. It comes from a few reasons.
 
1) RESTOREs. If you backup and RESTORE a project from one VSS to another, it loads it under orphaned, and under some circumstances, it fails to run properly after the restore happens. vss2svn fails to handle any RENAME on the RESTORED folder. (The restore action can rename the folder and restore it at the same time).
2) SHAREs. If a file is shared, and the parent is destroyed, any renames that happened will fail to show properly.
 
I have fixed both of these errors in my local copy of vss2svn and was planning on emailing the patches to the list. If you have it setup to run it as a perl environment, I can forward the patches when I get off work. They worked for me on my two VSS migrations.
 
Bryan

On Tue, Apr 22, 2008 at 8:40 AM, nandinicvs <ashu.ngm <at> gmail.com> wrote:

hi all,
I have created the dumpfile for my repository ...and then used svnadmin load
to create the repository out of the dumpfile.....I got the following
error....
<<< Started new transaction, based on original revision 6345
    * adding path : orphaned/_YGFBAAAA ... done.
    * adding path : orphaned/_YGFBAAAA/Report ... done.
    * adding path : orphaned/_ZHFBAAAA ... done.
    * adding path : orphaned/_ZHFBAAAA/ ... done.
    * adding path : orphaned/_NIFBAAAA ... done.
    * adding path : orphaned/_NIFBAAAA/App_ces ... done.
    * adding path : orphaned/_NJFBAAAA ... done.
    * adding path : orphaned/_NJFBAAAA/Service ... done.
    * adding path : orphaned/_RJFBAAAA ... done.
    * adding path : orphaned/_RJFBAAAA/Service ... done.
    * adding path : orphaned/_SJFBAAAA ... done.
    * adding path : orphaned/_SJFBAAAA/rService ... done.
    * adding path : orphaned/_WJFBAAAA ... done.
    * adding path : orphaned/_WJFBAAAA/Service ... done.
    * adding path : orphaned/_WJFBAAAA/M.....ade.d
iscomap ...svnadmin: File not found: revision 5831, path
'/orphaned/_UDBBAAAA/..///....sie.discomap'



any reasons why could this be and how to solve this????
Thank u in advance.....
--
View this message in context: http://www.nabble.com/error-while-creating-repository-from-dumpfile-tp16823841p16823841.html
Sent from the vss2svn - users mailing list archive at Nabble.com.

_______________________________________________
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


_______________________________________________
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
Nathan Kidd | 22 Apr 16:24

Re: error while creating repository from dumpfile

nandinicvs wrote:
> I have created the dumpfile for my repository ...and then used svnadmin load
> to create the repository out of the dumpfile.....I got the following
> error....
> <<< Started new transaction, based on original revision 6345
> iscomap ...svnadmin: File not found: revision 5831, path
> '/orphaned/_UDBBAAAA/..///....sie.discomap'
> 
> any reasons why could this be and how to solve this????

Googling for:

"svnadmin: File not found" vss2svn

returns in the first few results this page: 
http://www.pumacode.org/projects/vss2svn/wiki/FixingTheDumpfile

This is a manual approach which is good if you don't have too many 
errors, or don't want to re-run the conversion.  If Bryan's patches fix 
the source of the problem they're more ideal.

-Nathan

_______________________________________________
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

Bryan Aldrich | 22 Apr 17:53

Re: error while creating repository from dumpfile

I was able to get them from my house. They are attached.
 
Please be forwarned, I learned Perl making these fixes :)
Bryan
On Tue, Apr 22, 2008 at 10:24 AM, Nathan Kidd <nathan-svn <at> spicycrypto.ca> wrote:
nandinicvs wrote:
I have created the dumpfile for my repository ...and then used svnadmin load
to create the repository out of the dumpfile.....I got the following
error....
<<< Started new transaction, based on original revision 6345
iscomap ...svnadmin: File not found: revision 5831, path
'/orphaned/_UDBBAAAA/..///....sie.discomap'

any reasons why could this be and how to solve this????

Googling for:

"svnadmin: File not found" vss2svn

returns in the first few results this page: http://www.pumacode.org/projects/vss2svn/wiki/FixingTheDumpfile

This is a manual approach which is good if you don't have too many errors, or don't want to re-run the conversion.  If Bryan's patches fix the source of the problem they're more ideal.

-Nathan


_______________________________________________
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


Index: script/vss2svn.pl
===================================================================
--- script/vss2svn.pl	(revision 339)
+++ script/vss2svn.pl	(working copy)
@@ -722,6 +722,7 @@
     # the MergeParentData function can not deal with this specific problem

     my($sth, $rows, $row);
+    
     $sth = $gCfg{dbh}->prepare('SELECT * FROM PhysicalAction '
                                . 'WHERE actiontype = "MOVE_FROM"');
     $sth->execute();
@@ -738,19 +739,19 @@
         my $source = undef;
         my $target = $row->{parentphys};

-        if (scalar @$childrecs > 1) {
-            &ThrowWarning("Multiple child recs for parent MOVE rec "
-                          . "'$row->{action_id}'");
-        }
-
-        if (scalar @$childrecs >= 1) {
-            # only merge MOVE records that have the same timestamp
-            if ($row->{timestamp} == @$childrecs[0]->{timestamp}) {
-                $source = @$childrecs[0]->{parentphys};
-                &DeleteChildRec(@$childrecs[0]->{action_id});
-            }
-        }
-        
+	my $chosenChildRecord;
+	my $childRecord;
+	
+	foreach $childRecord (@$childrecs) {
+	    if (!(defined $chosenChildRecord) && $childRecord->{timestamp} == $row->{timestamp} &&
!($childRecord->{parentphys} eq $row->{parentphys})) {
+	        $chosenChildRecord = $childRecord;
+	    }
+	}
+	
+	if (defined $chosenChildRecord) {
+	    $source = $chosenChildRecord->{parentphys};
+	    &DeleteChildRec($chosenChildRecord->{action_id});
+	    
         my $sql = <<"EOSQL";
 UPDATE
     PhysicalAction
@@ -764,7 +765,31 @@
         my $update;
         $update = $gCfg{dbh}->prepare($sql);

-        $update->execute( $target, $source, $row->{action_id});
+        update->execute( $target, $source, $row->{action_id});
+	} else {
+	    #the record did not have a matching MOVE_TO. call it a RESTORE
+print "Changing $row->{action_id} to a RESTORE\n";
+            my $sql = <<"EOSQL";
+UPDATE
+    PhysicalAction
+SET
+    actiontype = 'RESTORE'
+WHERE
+    action_id = ?
+EOSQL
+            my $update;
+            $update = $gCfg{dbh}->prepare($sql);
+        
+            $update->execute( $row->{action_id});
+	}
+
+#        if (scalar @$childrecs >= 1) {
+#            # only merge MOVE records that have the same timestamp
+#            if ($row->{timestamp} == @$childrecs[0]->{timestamp}) {
+#                $source = @$childrecs[0]->{parentphys};
+#                &DeleteChildRec(@$childrecs[0]->{action_id});
+#            }
+#        }
     }

 
@@ -784,7 +809,26 @@
         $update->execute($row->{info}, $row->{parentphys}, $row->{action_id});
     }

+    $sth = $gCfg{dbh}->prepare('SELECT * FROM PhysicalAction WHERE actiontype = "RESTORE"');
+    $sth->execute();
+    $rows = $sth->fetchall_arrayref( {} );
+    
+    foreach $row (@$rows) {
+        #calculate last name of this file. Store it in $info
+            
+        my $sql = "SELECT * FROM PhysicalAction WHERE physname = ? AND timestamp < ? ORDER BY timestamp DESC";
+	        
+        $sth = $gCfg{dbh}->prepare($sql);
+        $sth->execute( $row->{physname}, $row->{timestamp} );
+	        	
+        my $myOlderRecords = $sth->fetchall_arrayref( {} );

+        if (scalar @$myOlderRecords > 0) {
+            my $update = $gCfg{dbh}->prepare('UPDATE PhysicalAction SET info = ? WHERE action_id = ?');
+            $update->execute(@$myOlderRecords[0]->{itemname}, $row->{action_id});
+    	}
+    }
+
     1;

 }  #  End MergeMoveData
Index: script/Vss2Svn/ActionHandler.pm
===================================================================
--- script/Vss2Svn/ActionHandler.pm	(revision 339)
+++ script/Vss2Svn/ActionHandler.pm	(working copy)
@@ -113,7 +113,7 @@
     # number here. So we don't need to add the item anyway.
     if (!defined $version ) {
         $self->{errmsg} .= "Attempt to add entry '$row->{physname}' with "
-            . "unknown version number (probably destroyed)\n";
+            . "unknown version number (probably destroyed) parent: $row->{parentphys} itemtype: $row->{itemtype}\n";

         $gOrphanedInfo {$row->{physname} } = 1;
         return 0;
@@ -263,6 +263,10 @@
     my $parentpath = $self->_get_current_parent_path ();
     my $itempath = $parentpath . $row->{itemname};

+    # a SHARE *can* rename a file if the parent is no longer present.
+    $row->{info} = $row->{itemname};
+    $self->_rename_handler();
+
     # 'sourceinfo' contains the source path
     my $sourceinfo = $self->_get_valid_path ($physname, $row->{parentphys}, $version);

@@ -276,15 +280,16 @@
 #        return $self->_add_handler();
     }

+    ## Can not MOVE from orphan if SHARE. The orphaned item may move later as part of a standard move.
     # if this is a share from orphan, and not a share+pin action either, we can treat it as a move
-    elsif (!defined $row->{version} &&        # share+pin?
-           defined $physinfo->{orphaned}      # orphaned?
-#          scalar @{$physinfo->{order}} == 1  # only one parent?
-       ) {
-        $physinfo->{parents}->{'_' . $row->{physname}}->{deleted} = 1;
-        undef $physinfo->{orphaned};
-        $self->{action} = 'MOVE';
-    }
+#    elsif (!defined $row->{version} &&        # share+pin?
+#           defined $physinfo->{orphaned}      # orphaned?
+##          scalar @{$physinfo->{order}} == 1  # only one parent?
+#       ) {
+#        $physinfo->{parents}->{'_' . $row->{physname}}->{deleted} = 1;
+#        undef $physinfo->{orphaned};
+#        $self->{action} = 'MOVE';
+#    }

     # track the addition of the new parent
     $self->_add_parent ($physname, $row->{parentphys});
@@ -410,7 +415,7 @@
 #  _move_handler
 ###############################################################################
 sub _move_handler {
-    my($self) = @_;
+    my($self, $oldName) = @_;
     my $row = $self->{row};

     my $physname = $row->{physname};
@@ -439,11 +444,6 @@
       }
     }

-    # '$sourceinfo' is the path for the old location (the move source);
-    my $sourceparent = $self->_get_parent_path ($row->{info});
-    my $sourceinfo = $sourceparent . $row->{itemname};
-
-
     # check the target path
     if (!defined ($row->{parentphys})) {
         # the target directory was destroyed, so there is no apropriate move
@@ -452,6 +452,18 @@
         $row->{parentphys} = '_' . $row->{physname};
     }

+    # '$sourceinfo' is the path for the old location (the move source);
+    my $sourceparent = $self->_get_parent_path ($row->{info});
+    my $sourceinfo;
+    if (defined $oldName)
+    {
+    	$sourceinfo = $sourceparent . $oldName;
+    }
+    else
+    {
+        $sourceinfo = $sourceparent . $row->{itemname};
+    }
+
     # '$itempath' contains the move target path
     my $parentpath = $self->_get_current_parent_path ();
     my $itempath = $parentpath . $physinfo->{name}; # $row->{itemname};
@@ -494,9 +506,26 @@

     $self->{action} = 'MOVE';
     $row->{actiontype} = 'MOVE';
-    $row->{info} = $row->{parentphys};
-    $row->{parentphys} = '_' . $row->{physname};
-    return $self->_move_handler ();
+#    $row->{info} = $row->{parentphys};
+#    $row->{parentphys} = '_' . $row->{physname};
+    
+    $gPhysInfo{ $row->{physname} } =
+        {
+         type       => $row->{itemtype},
+         name       => $row->{itemname},
+         parents    => {},
+         first_version => 1,
+         last_version => 1,
+         orphaned   => 1,
+         was_binary => $row->{is_binary},
+    };
+    
+    my $newName = $row->{info};
+    
+    # the MOVE handler uses info, but expects it to be undef for a restore action.
+    undef $row->{info};
+
+    return $self->_move_handler ($newName);
 }

 ###############################################################################
Index: script/Vss2Svn/Dumpfile.pm
===================================================================
--- script/Vss2Svn/Dumpfile.pm	(revision 339)
+++ script/Vss2Svn/Dumpfile.pm	(working copy)
@@ -205,9 +205,13 @@
             return $self->_commit_handler ($itempath, $nodes, $data, $expdir);
         }
         else {
-            $self->add_error("Attempt to re-add directory '$itempath' at "
-                . "revision $data->{revision_id}, skipping action: possibly "
-                . "missing delete");
+            #creating a new VSS database can cause a "ADD" for a "/" item which will fail.
+            if (!($itempath eq "/")) {
+        	$self->add_error("Attempt to re-add directory '$itempath' at "
+                    . "revision $data->{revision_id}, skipping action: possibly "
+                    . "missing delete");
+            }
+            
             return 0;
         }
     }
@@ -219,9 +223,13 @@
         return 0;
     }
     elsif ($success == 0) {
-        $self->add_error("Parent path missing while trying to add "
-            . "item '$itempath' at revision $data->{revision_id}: adding missing "
-            . "parents");
+        # don't warn about adding missing parents for orphans. they are always missing.
+    	if (!($itempath =~ m/^\/orphaned\/_.*/))
+    	{
+	    $self->add_error("Parent path missing while trying to add "
+	        . "item '$itempath' at revision $data->{revision_id}: adding missing "
+	        . "parents");
+		}
         $self->_create_svn_path ($nodes, $itempath);
     }

_______________________________________________
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
Toby Johnson | 25 May 17:18

Re: error while creating repository from dumpfile

Bryan Aldrich wrote:
> I was able to get them from my house. They are attached.
>  
> Please be forwarned, I learned Perl making these fixes :)
> Bryan

Thanks Bryan, has anyone else had a chance to test the patches? Should 
these be added to trunk?

toby

_______________________________________________
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

Bryan Aldrich | 25 May 19:33

Re: error while creating repository from dumpfile

I thought they already had been. I posted them in a seperate thread as well.
 
Bryan

On Sun, May 25, 2008 at 11:18 AM, Toby Johnson <toby <at> etjohnson.us> wrote:
Bryan Aldrich wrote:
I was able to get them from my house. They are attached.
 Please be forwarned, I learned Perl making these fixes :)
Bryan

Thanks Bryan, has anyone else had a chance to test the patches? Should these be added to trunk?

toby


_______________________________________________
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


_______________________________________________
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
Toby Johnson | 25 May 23:37

Re: error while creating repository from dumpfile

Bryan Aldrich wrote:
> I thought they already had been. I posted them in a seperate thread as 
> well.

OK thanks, I couldn't remember if they were the same. I've gotten a bit 
behind on my mailing lists!

toby

_______________________________________________
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

More patches for vss2svn

Hello,

For the last two weeks I have been trying to convert our project's VSS 
repository to SVN, and last Friday I finally succeded in producing a 
Subversion repository, that does not deviate in it's final state from the VSS 
one, and has reasonable coverage of the past history. Since the part of the 
repository that I tried to convert has more than 10 years of data on about 
30000 files, not counting branches, and, naturally, is a bit corrupted, it's 
impossible to ensure 100% correctness anyway.

As the patches that I added in order to achieve that goal might be useful for 
others, I want to share them here.

Of 11 patches, 4 address memory usage issues on large repositories, 3 add 
enhancements to vss2svn, and 4 fix bugs.

Their description is as follows:

0001-Added-an-option-to-reuse-text-files-of-the-cache-for.patch

  This patch adds an option, which, when activated, makes vss2svn reuse 
temporary files left from previous runs, thus avoiding costly calls to 
ssphys. It is useful during experimenting.

0002-Added-visual-progress-indication.patch

  Adds progress indication to most of the steps. 

0003-Reimplemented-LoadVssNames-to-use-XML-Parser-direct.patch

  On our repository, loading the xml file via XML::Simple consumes about 1GB 
of memory. That is unacceptable, so this patch reimplements that step to use 
XML::Parser. I'm not familiar with it, so I might have missed some difficult 
cases, e.g. maybe handling things like "&amp;" in names.

0004-Use-arrays-for-table-data-storage-in-order-to-avoid.patch

  Use array of arrays instead of an array of hashes to hold entries in 
MergeParentData, to save some memory. 

0005-Use-a-sliding-window-limited-by-timestamp-range-to-c.patch

  MergePinUnpin doesn't need to load the whole table into memory at once, it's 
enough to hold a timestamp-limited range of records.

0006-Do-not-fetch-the-table-into-memory-in-BuildComments.patch

  BuildComments doesn't need to load the table at all, it's better to keep a 
list of records to update afterwards. Also fixes a bug in newline handling.

0007-Added-options-to-prune-orphaned-files-and-labels-fro.patch

  Most of orphans in that repository come from unneeded projects removed 
before conversion. This patch adds an option to automatically remove all 
orphans, except for the ones absolutely necessary for correct conversion. 
Doing it on the stage of computing the set of actions guarantees a valid dump 
file.

  Without removing orphans, SVN consumes about 200KB per revision (apparently, 
it cannot diff directories, and the /orphaned dir gets very large).

0008-Fixed-a-problem-in-chain-share-handling.patch

  In some cases, when a file is shared into a path, branched, then immediately 
reshared to another path, etc, vss2svn generates a command to copy from the 
current revision, and svnadmin doesn't like that. This quick fix avoids the 
problem by beginning a new revision on shares from a path, that was touched 
by the current revision.

0009-Fixed-a-bug-in-handling-restore-with-labels.patch

  Fixes a bug in the recent patch, which produces invalid paths if the last 
action in a restored project was adding a label.

  I'm not sure about this bit, I just thought it strange that we should 
completely reset the version numbers, even if they are available:

@@ -474,13 +474,18 @@ sub _restore_handler {
          type       => $row->{itemtype},
          name       => $row->{itemname},
          parents    => {},
-         first_version => 1,
-         last_version => 1,
+         first_version => $gPhysInfo{ $row->{physname} }{first_version} || 1,
+         last_version => $gPhysInfo{ $row->{physname} }{last_version} || 1,
          orphaned   => 1,
          was_binary => $row->{is_binary},
     };

0010-Recover-files-with-corrupted-history-at-branch-point.patch

  In the trunk version, if a physical file is lost, all files, branched from 
it, are not converted, despite the fact that all versions after the branch 
are available. This patch adds a check to re-add such files at the branch 
point.

0011-Support-rolling-back-during-branching.patch

  Branching CAN be combined with rollback, so it's not always a no-op in SVN. 
This patch introduces a new ROLLBACK action to handle that case.

P.S. Is it by design that Subversion stores all 110000 revisions in one 
directory?

Alexander
_______________________________________________
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
Jonathan Perret | 28 May 11:12

RE: More patches for vss2svn

Alexander N. Gavrilov wrote :
> Subject: More patches for vss2svn

Alexander,
Your patches sound very useful and I hope they can be integrated into
the trunk to help future users.

I just thought I'd reply to this question :

> P.S. Is it by design that Subversion stores all 110000 revisions in
one
> directory?

This has long been recognized a potential source of concern (though in
fact, benchmarks tend to show it is not a problem for most UNIX
filesystems) in the FSFS backend, and it is being addressed in
Subversion 1.5 :
http://subversion.tigris.org/svn_1.5_releasenotes.html#fsfs-sharding

Cheers,
--Jonathan

_______________________________________________
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

Toby Johnson | 29 May 01:23

Re: More patches for vss2svn

Alexander N. Gavrilov wrote:
> Hello,
>
> For the last two weeks I have been trying to convert our project's VSS 
> repository to SVN, and last Friday I finally succeded in producing a 
> Subversion repository, that does not deviate in it's final state from the VSS 
> one, and has reasonable coverage of the past history. Since the part of the 
> repository that I tried to convert has more than 10 years of data on about 
> 30000 files, not counting branches, and, naturally, is a bit corrupted, it's 
> impossible to ensure 100% correctness anyway.
>   

Hello Alexander,

Thanks for all the hard work you've put into your patches! I wish I 
would have known ahead of time that you would be submitting so many, I 
could have given you commit access on your own branch to make managing 
and reviewing them easier. In fact I will still probably create a branch 
for these just so I can keep track while I commit them. I'll reply back 
once I've got them committed and hopefully others can help with 
reviewing/testing.

Thanks again,
toby

_______________________________________________
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

Re: More patches for vss2svn

On Thursday 29 May 2008 03:23:27 Toby Johnson wrote:
> Thanks for all the hard work you've put into your patches! I wish I
> would have known ahead of time that you would be submitting so many, I
> could have given you commit access on your own branch to make managing
> and reviewing them easier. In fact I will still probably create a branch
> for these just so I can keep track while I commit them. I'll reply back
> once I've got them committed and hopefully others can help with
> reviewing/testing.

Hello,

Well, I didn't know that myself. I just tweaked one thing, then another, and 
so on.  =)

Actually, this conversion was some sort of a feasibility study. If the big 
bosses agree to do an actual switch, I'll be converting everything afresh, 
probably with a slightly different set of projects; besides, there is a 
completely separate repository of the QA group, undoubtely with it's own 
quirks. In that case I might have to do some more changes, and committing 
them directly to a separate branch would indeed be more convenient. However, 
I don't expect that to be very soon.

In the meanwhile, after some hacking on git-svnimport I also succeeded in 
further converting the repository to Git, and during this weekend wrote a 
script for bidirectional exchange of simple changes between Git and VSS, 
using VSS's logging facility. It's still full of bugs, though...

Alexander.

_______________________________________________
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


Gmane