On May 31, 2007, at 1:41 AM, Lele Gaifax wrote:
Scott Lamb writes:
Scott> TRY 1 =====
...
Uhm, two things: first, I'm afraid it's not enough to alter the name
of the entry as you did, but the concrete file on the filesystem
should be moved too
Hmm...in hindsight, I don't know how I expected this to work.
Moving the concrete files sounds impractical, though, as my later svn
commands need to work. Is there an easy way to instead manipulate the
chdir of the git/hg commands? Maybe this is what you are getting at
with the 'subdir' below, but I don't really understand.
Scott> TRY 2 =====
...
Scott> Not real successful this way either. First, I noticed
Scott> there's no "end- revision" property to go with
Scott> "start-revision". There's also this:
Yes, this should be added, it's just so a common request! I needed
this just once, and used before-commit to cut off the tail of
changesets...
Scott> 21:20:09 [I] /tmp/test $ svn log --verbose --xml
Scott> --revision 579 21:20:09 [W] [Status 1] 21:20:09 [C]
Scott> Checkout of sigsafe failed!
Scott> It appears that "svn log --revision 579
Scott> https://www.slamb.org/svn/ projects/[EMAIL PROTECTED]" succeeds,
Scott> but "svn log --revision 579 https://
Scott> www.slamb.org/svn/projects/sigsafe" looks for the history
Scott> of the node at that path in head. It fails. The WC-relative
Scott> path functions in the same way. The latter case seems
Scott> pretty lame to me (should know what node I'm talking about
Scott> from the revision of the wc), but that's how it is as of
Scott> subversion 1.4.2.
Sorry, I'm not sure to understand the implications of this.
What I'm saying is that any time you do this,
$ svn mkdir foo
$ svn ci -m 'revision 1'
$ svn mv foo bar
$ svn ci -m 'revision 2'
$ svn up --revision 1
$ svn log --revision 1 foo
the last command will fail. It seems to be looking for the node
referred to by [EMAIL PROTECTED], then showing log entries in the range [1,
HEAD].
On the other hand, this command,
$ svn log foo
will succeed. It appears to find the node referred to by [EMAIL PROTECTED],
then show its full revision history.
Now, what this means for tailor...hmm:
1. if you assume the top-level project directory never gets moved
(i.e., no one's as dumb as me), there's no problem.
2. if you want to allow it being moved only between "end-revision"
and HEAD, the log command needs to change. It looks like either "svn
log --revision %s:%s" % (start_revision, end_revision) or "svn log --
revision %s [EMAIL PROTECTED]" % (start_revision, end_revision) would work.
3. if you want to allow it being moved during the range to be
imported...then I don't think you can look ahead at log messages with
one command like this. The log command is looking for the node that
lives at this path at the end of the revision range. In my case,
there isn't one anymore. It could also be a totally different node if
I later move something else into that path. Subversion doesn't seem
to supply a command that shows the history over revisions [x, z] of a
node with lived at path p during revision y, for x < y < z. Given
this complexity and other problems with following the moves, maybe
it's best to not allow this. Instead, just document that it doesn't
work and that people who have this problem should import the before-
move and after-move pieces separately.
I'm playing with a patch that does #2, though it's kludgy so far.
Scott> TRY 3 =====
Scott> produce with "svnadmin dump" and "svnadmin restore" a
Scott> Subversion working copy with the history in one path, then
Scott> run tailor. Seems doable in concept, but "svndumpfilter"
Scott> doesn't have options for adjusting paths - just including
Scott> and excluding them - so I'd need to roll my own tool.
IIRC, there was a svndumpfilter implemented in Python, that allowed
such things.
Oh yeah, kind of remember that. Maybe I'll dig it up.
Anyway, have you tried using different nested working dirs? I mean
something like:
Hmm, I don't really understand what you mean, so I'm having trouble
filling in the gaps in this config file.
What is subdir? "tailor --help" says this:
--subdir=DIR Force the subdirectory where the checkout
will happen,
by default it's the tail part of the module
name.
so this is the directory where "svn co" is being run? No, there must
be more to it than that, because you're putting "subdir" into the
target repository sections as well.
Repository seems to set self.basedir according to subdir. So it looks
like a more specific subdir in the target repo will make it just
include a subset of the source repo, which is what I want. Okay, to
make this concrete I'm trying this exact config:
[DEFAULT]
verbose = True
git-command = /usr/local/bin/git
projects = proj_a, proj_b
[proj_a]
source = svn:proj_a
target = git:proj_a
root-directory = /tmp/test
[proj_b]
source = svn:proj_b
target = git:proj_b
root-directory = /tmp/test
[svn:proj_a]
repository = https://www.slamb.org/svn/repos
module = /
subdir = projects/sigsafe
[svn:proj_b]
repository = https://www.slamb.org/svn/repos
module = /
subdir = trunk/projects/sigsafe
[git:proj_a]
repository = /tmp/sigsafe.git
subdir = projects/sigsafe
[git:proj_b]
repository = /tmp/sigsafe.git
subdir = trunk/projects/sigsafe
...without any hooks to adjust paths. It's successfully importing all
kinds of non-sigsafe things, so it looks like "subdir" isn't doing
what I think it would on the git side. I would have expected this to
fail without a hook because Subversion is telling it about foobar
(meaning /tmp/test/foobar), and /tmp/test/projects/sigsafe/foobar
doesn't exist. git isn't honoring the subdir?
--
Scott Lamb <http://www.slamb.org/>
_______________________________________________
Tailor mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/tailor
