[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

svndumpfilter: Invalid copy source path

From: Martin Blais <blais_at_furius.ca>
Date: 2006-04-25 07:55:33 CEST

Hello Subversioners

About the "svndumpfilter: Invalid copy source path " copy/move problem
mentioned in:

  http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=36941

and

  http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=47462

I'm having this problem too. I'm not so concerned about keeping the
history of the move, but I do want to split the repository and obtain
one that is working nevertheless.

So I wrote some tests because I found the following paragraph from the
documentation to be ambiguous (from chap.5):

    Also, copied paths can give you some trouble. Subversion supports
    copy operations in the repository, where a new path is created by
    copying some already existing path. It is possible that at some
    point in the lifetime of your repository, you might have copied a
    file or directory from some location that svndumpfilter is
    excluding, to a location that it is including. In order to make
    the dump data self-sufficient, svndumpfilter needs to still show
    the addition of the new path—including the contents of any files
    created by the copy—and not represent that addition as a copy from
    a source that won't exist in your filtered dump data stream. But
    because the Subversion repository dump format only shows what was
    changed in each revision, the contents of the copy source might
    not be readily available. If you suspect that you have any copies
    of this sort in your repository, you might want to rethink your
    set of included/excluded paths.

Now that I wrote my tests the picture is clear that svndumpfilter does
not do that, but when I the above it was not very clear what it
actually does (this paragraph should be clarified IMO).

I noted that once svndumpfilter finds that a file has invalid copy
source path (i.e. it spits the error), it seems to ignore changes that
occur to that file later on, even if those changes record and entire
copy of the file to the revision. I suppose it makes sense, since it
could not get the original copy in the first place, to ignore all
actions on it thereafter.

Fiddling more into the dumpfile, I noticed that the change looks like
this::

  Node-path: p2/file1
  Node-kind: file
  Node-action: add
  Node-copyfrom-rev: 2
  Node-copyfrom-path: p1/file1

To circumvent the problem, would it not be possible to process the
dumpfile to convert those into additions? i.e.

1. Dump the entire repository

2. Process the dumpfile to convert some moves and copies into
   additions, fetching the required revisions using ``svn cat``.

   (Note that this could possibly happen for only particular
   move/copy occurrences, depending on rules set for the specific
   repo layout. My problem is the very same that is described in
   the documentation.)

3. Split the dump into two files, no problems should occur.

In addition, this hypothetical program could add a
svn:deleted-history property to the added file, to somehow record
some information about the fact that this "added file" really used
to be a modified copy/move.

Does this make sense? Do you think that this is possible?

I'm not very familiar with Subversion dumpfiles or repository management,
but if the above idea makes sense, I could whip up a Python script to
do this, easy peasy (I need this now). Let me know if you see potential
problems with my description above, it seems like a really simple
and clean workaround to me.

Any information appreciated.
cheers,

--
Martin Blais
Furius Python Training -- http://furius.ca/training/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 25 07:56:27 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.