On 09/04/2008, Björn Steinbrink <B.Steinbrink@xxxxxx> wrote:
> [Grmpf, the next time you drop from me Cc:, I'll not bother to
> answer...]
Fixed; sorry.
> On 2008.04.08 21:43:03 +0100, Thomas Leonard wrote:
[...]
> > The script that made the releases simply did this ("." is the working copy):
> >
> > svn cp -m "Released $VERSION" . http://...
> >
> > Since each file in an svn working copy has its own revision (the last
> > time it was changed), the branch ends up with multiple source
> > revisions, even if the working copy is fully up-to-date and has no
> > local changes.
> >
> > Example:
> >
> > cd /tmp
> > svnadmin create test-repo
> > svn mkdir file:///tmp/test-repo/trunk -m 'Setup'
> > svn co file:///tmp/test-repo/trunk
> > cd trunk
> > touch foo bar
> > svn add foo bar
> > svn ci -m 'Start'
> > echo hi > bar
> > svn ci -m 'Update'
> > svn cp . file:///tmp/test-repo/release -m 'Release'
> > svn log -v file:///tmp/test-repo
> >
> > The log shows:
> >
> > ------------------------------------------------------------------------
> > r4 | talex | 2008-04-08 21:35:44 +0100 (Tue, 08 Apr 2008) | 1 line
> > Changed paths:
> > A /release (from /trunk:1)
> > A /release/bar (from /trunk/bar:3)
> > A /release/foo (from /trunk/foo:2)
> >
> > Release
>
> Change the "." to "file:///tmp/test-repo/trunk" in the svn cp command
> and you get:
> Changed paths:
> A /release (from /trunk:3)
>
> Seems more useful. No idea why SVN decides to record crap when you use
> ".", even when your working copy is clean.
That's good advice, but I'm wondering how to convert my existing svn
repositories to GIT.
> > So, I don't think the metadata is broken in this case. Maybe other
> > people don't create branches like this, but it seemed like the obvious
> > way to do it at the time. Given this behaviour of svn, perhaps it
> > would be better to take the highest version number as the branch
> > point?
>
> Uhm, and what happens then, when you actually _did_ just copy over a
> few files, but not all of them? Right, you get a branch to start at a
> later revision and see a bunch of reverts. Equally broken.
Sure, if you create a situation that GIT can't represent then there's
nothing much git-svn can do.
However, when there are different source revisions:
- Taking the highest revision will give correct results in the common
case, and "equally broken" results in the uncommon case.
- Taking any other revision (the current behaviour) is guaranteed to
give the wrong result. There's no way a branch that was created with a
file from revision 6 can possibly be a branch of revision 5, for
example.
Also, the current behaviour can be wildly out (e.g. revision 1894 when
it should have been 2070, in the previous real example). The highest
revision is unlikely to be far off.
--
Dr Thomas Leonard http://rox.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
