[Feature Request] Better Subversion integration

[Feature Request] Better Subversion integration

[Sam Granieri Jr]

Right now, git-svn import (or clone) will convert tags and branches as  
remote branches.
I would like it if git could pick up subversion tags and translate  
them as git tags upon importing

I also have some concerns with git-svn dcommit

Would it be possible for git-svn dcommit to convert locally created  
git tags to subversion tags? How about branches?

Or is git-svn dcommit only meant to push the current working  (git )  
branch to whatever (svn) branch you checked out from?

I've been using git since december and I'm trying to convert everyone  
I know to it from subversion. Unfortunately, I need to use subversion  
at work. Gits a great tool and I intend to be using it for a while.

Sam

Re: [Feature Request] Better Subversion integration

[Björn Steinbrink]

On 2008.02.09 20:44:59 -0600, Sam Granieri Jr wrote:
> Right now, git-svn import (or clone) will convert tags and branches as  
> remote branches.
> I would like it if git could pick up subversion tags and translate them 
> as git tags upon importing

SVN tags aren't like git tags. A "tag" in SVN is just another directory,
which you can modify at will. Yeah, I know, you _should_ not commit any
changes to SVN "tags", but shit happens. And once you modify the "tag"
in SVN, you would have to invalidate the git tag, and finding a commit
that matches the SVN state of things is probably way too expensive to be
practical. Maybe some --we-never-mess-up-svn-tag-alike-branches could
be added to allow git-svn to create teal git tags though? Dunno, I don't
care much. Shouldn't be too hard to find some shell magic to create
tags, if one wants them.

> I also have some concerns with git-svn dcommit
>
> Would it be possible for git-svn dcommit to convert locally created git 
> tags to subversion tags? How about branches?

Didn't need to convert tags yet, but I have a small shell script that
does branching for me (see below). What it does, is to simply look at
the history and figure out the first commit that exists in SVN. Then it
invokes the svn program and creates a branch in SVN, starting at that
commit. Then you can just fetch that branch, rebase your work and commit
away. Writing a similar hack for tags shouldn't be too hard.

For example (assuming that you saved the script as git-svn-branch):
git checkout -b my_branch remotes/trunk
// work work work
.oO( Hm, maybe I should put that into a SVN branch for foobar reason )
git-svn-branch my_branch
git svn fetch
git rebase --onto remotes/my_branch remotes/trunk my_branch
git svn dcommit -n # This should now (pretend to) dcommit to my_branch

One thing it gets wrong (probably, never tried) is that it will take the
wrong starting point when you cherry-picked a commit from another SVN
branch and didn't remove the git-svn-id line. That is because it doesn't
make use of the .rev_map files and thus cannot figure out if the
git-svn-id line is actually valid.

IIRC git-svn should handle such cherry-picks gracefully, so
integrating that thing with git-svn would have some benefits, but I
don't speak any perl. Maybe someone else wants to take the job?

HTH
Björn


#!/bin/sh
if test "$1" = ''
then
	echo "Usage: git-svn-branch <branch_name>"
	exit 127
fi

CURRENT=$(git rev-list --first-parent --pretty=format:%b HEAD | grep -m1 -o 'git-svn-id: [^ ]*' | sed -e 's/git-svn-id: //')

SRC=${CURRENT%@*}
REV=${CURRENT#*@}
URL=$(git config --get svn-remote.svn.url)

URL=$(echo -n "$URL" | sed -e 's!//.*@!//!')
DST="$URL/$(git config --get svn-remote.svn.branches | grep -o '^[^:]*' | sed -e "s/\*/$1/")"

svn cp -r "$REV" "$SRC" "$DST" -m "Create branch $1"

Re: [Feature Request] Better Subversion integration

[Michael Haggerty]

Björn Steinbrink wrote:
> On 2008.02.09 20:44:59 -0600, Sam Granieri Jr wrote:
>> Right now, git-svn import (or clone) will convert tags and branches as  
>> remote branches.
>> I would like it if git could pick up subversion tags and translate them 
>> as git tags upon importing
> 
> SVN tags aren't like git tags. A "tag" in SVN is just another directory,
> which you can modify at will. Yeah, I know, you _should_ not commit any
> changes to SVN "tags", but shit happens. And once you modify the "tag"
> in SVN, you would have to invalidate the git tag, and finding a commit
> that matches the SVN state of things is probably way too expensive to be
> practical. Maybe some --we-never-mess-up-svn-tag-alike-branches could
> be added to allow git-svn to create teal git tags though? Dunno, I don't
> care much. Shouldn't be too hard to find some shell magic to create
> tags, if one wants them.

Because of the way an SVN repository is stored, it should be cheap to
ask SVN whether the contents of a tag in the HEAD revision are identical
to the contents at the time the tag was created.  If there was any
change anywhere under the tag directory, then the node of the tag
directory will be different in the two revisions.

For that matter, you could ask SVN for information about the revisions
in which the tags/ directory was changed (this is also very cheap), and
make sure that none of those changes modified an existing tag.  This
scan could be done at the beginning of a conversion to determine which
tags were handled as pure tags (and therefore convertible as git tags)
and which were not (and therefore require more complicated handling).

Michael

Re: [Feature Request] Better Subversion integration

[Björn Steinbrink]

On 2008.02.10 17:52:15 +0100, Michael Haggerty wrote:
> Björn Steinbrink wrote:
> > On 2008.02.09 20:44:59 -0600, Sam Granieri Jr wrote:
> >> Right now, git-svn import (or clone) will convert tags and branches as  
> >> remote branches.
> >> I would like it if git could pick up subversion tags and translate them 
> >> as git tags upon importing
> > 
> > SVN tags aren't like git tags. A "tag" in SVN is just another directory,
> > which you can modify at will. Yeah, I know, you _should_ not commit any
> > changes to SVN "tags", but shit happens. And once you modify the "tag"
> > in SVN, you would have to invalidate the git tag, and finding a commit
> > that matches the SVN state of things is probably way too expensive to be
> > practical. Maybe some --we-never-mess-up-svn-tag-alike-branches could
> > be added to allow git-svn to create teal git tags though? Dunno, I don't
> > care much. Shouldn't be too hard to find some shell magic to create
> > tags, if one wants them.
> 
> Because of the way an SVN repository is stored, it should be cheap to
> ask SVN whether the contents of a tag in the HEAD revision are identical
> to the contents at the time the tag was created.  If there was any
> change anywhere under the tag directory, then the node of the tag
> directory will be different in the two revisions.
> 
> For that matter, you could ask SVN for information about the revisions
> in which the tags/ directory was changed (this is also very cheap), and
> make sure that none of those changes modified an existing tag.  This
> scan could be done at the beginning of a conversion to determine which
> tags were handled as pure tags (and therefore convertible as git tags)
> and which were not (and therefore require more complicated handling).

Yeah, but what if a "tag" in SVN is modified after that? Then the git
tag becomes kinda invalid, and I see no cheap way to figure out if there
is a commit somewhere that has the same content of the new "tag". That's
what I'm talking about.

The only way I see to handle that is to create a new commit in git and
tag that. But IMHO that's totally nuts, because the tag doesn't even
point to a commit of the "real" branch anymore. And you'd either need to
replace/remove the old tag or use a naming scheme that includes some
@rev marker, both of which are just confusing when talking about tags.

Björn

Re: [Feature Request] Better Subversion integration

[Michael Haggerty]

Björn Steinbrink wrote:
> On 2008.02.10 17:52:15 +0100, Michael Haggerty wrote:
>> Björn Steinbrink wrote:
>>> On 2008.02.09 20:44:59 -0600, Sam Granieri Jr wrote:
>>>> Right now, git-svn import (or clone) will convert tags and branches as  
>>>> remote branches.
>>>> I would like it if git could pick up subversion tags and translate them 
>>>> as git tags upon importing
>>> SVN tags aren't like git tags. A "tag" in SVN is just another directory,
>>> which you can modify at will. Yeah, I know, you _should_ not commit any
>>> changes to SVN "tags", but shit happens. And once you modify the "tag"
>>> in SVN, you would have to invalidate the git tag, and finding a commit
>>> that matches the SVN state of things is probably way too expensive to be
>>> practical. Maybe some --we-never-mess-up-svn-tag-alike-branches could
>>> be added to allow git-svn to create teal git tags though? Dunno, I don't
>>> care much. Shouldn't be too hard to find some shell magic to create
>>> tags, if one wants them.
>> Because of the way an SVN repository is stored, it should be cheap to
>> ask SVN whether the contents of a tag in the HEAD revision are identical
>> to the contents at the time the tag was created.  If there was any
>> change anywhere under the tag directory, then the node of the tag
>> directory will be different in the two revisions.
>>
>> For that matter, you could ask SVN for information about the revisions
>> in which the tags/ directory was changed (this is also very cheap), and
>> make sure that none of those changes modified an existing tag.  This
>> scan could be done at the beginning of a conversion to determine which
>> tags were handled as pure tags (and therefore convertible as git tags)
>> and which were not (and therefore require more complicated handling).
> 
> Yeah, but what if a "tag" in SVN is modified after that? Then the git
> tag becomes kinda invalid, and I see no cheap way to figure out if there
> is a commit somewhere that has the same content of the new "tag". That's
> what I'm talking about.
> 
> The only way I see to handle that is to create a new commit in git and
> tag that. But IMHO that's totally nuts, because the tag doesn't even
> point to a commit of the "real" branch anymore. And you'd either need to
> replace/remove the old tag or use a naming scheme that includes some
> @rev marker, both of which are just confusing when talking about tags.

You're right; when importing incrementally there is no way to know what
people will do with a tag after the initial conversion.  I was thinking
more of a one-time conversion.

If a new tag is created cleanly in subversion (that is, a single copy
from a single location, then you can read the SVN source (trunk or
branch name + SVN revision number) directly out of SVN.  A persistent
look-up table could keep track of the git hashes corresponding to such
sources.

If a clean tag is later modified, would it be reasonable to
"retroactively" create a git branch based on the contents of the old
tag, and modify that?

The general case is certainly not easy, but some standard, easy cases
could probably be covered.

Michael

Re: [Feature Request] Better Subversion integration

[Björn Steinbrink]

On 2008.02.10 20:36:34 +0100, Michael Haggerty wrote:
> Björn Steinbrink wrote:
> > On 2008.02.10 17:52:15 +0100, Michael Haggerty wrote:
> >> Björn Steinbrink wrote:
> >>> On 2008.02.09 20:44:59 -0600, Sam Granieri Jr wrote:
> >>>> Right now, git-svn import (or clone) will convert tags and branches as  
> >>>> remote branches.
> >>>> I would like it if git could pick up subversion tags and translate them 
> >>>> as git tags upon importing
> >>> SVN tags aren't like git tags. A "tag" in SVN is just another directory,
> >>> which you can modify at will. Yeah, I know, you _should_ not commit any
> >>> changes to SVN "tags", but shit happens. And once you modify the "tag"
> >>> in SVN, you would have to invalidate the git tag, and finding a commit
> >>> that matches the SVN state of things is probably way too expensive to be
> >>> practical. Maybe some --we-never-mess-up-svn-tag-alike-branches could
> >>> be added to allow git-svn to create teal git tags though? Dunno, I don't
> >>> care much. Shouldn't be too hard to find some shell magic to create
> >>> tags, if one wants them.
> >> Because of the way an SVN repository is stored, it should be cheap to
> >> ask SVN whether the contents of a tag in the HEAD revision are identical
> >> to the contents at the time the tag was created.  If there was any
> >> change anywhere under the tag directory, then the node of the tag
> >> directory will be different in the two revisions.
> >>
> >> For that matter, you could ask SVN for information about the revisions
> >> in which the tags/ directory was changed (this is also very cheap), and
> >> make sure that none of those changes modified an existing tag.  This
> >> scan could be done at the beginning of a conversion to determine which
> >> tags were handled as pure tags (and therefore convertible as git tags)
> >> and which were not (and therefore require more complicated handling).
> > 
> > Yeah, but what if a "tag" in SVN is modified after that? Then the git
> > tag becomes kinda invalid, and I see no cheap way to figure out if there
> > is a commit somewhere that has the same content of the new "tag". That's
> > what I'm talking about.
> > 
> > The only way I see to handle that is to create a new commit in git and
> > tag that. But IMHO that's totally nuts, because the tag doesn't even
> > point to a commit of the "real" branch anymore. And you'd either need to
> > replace/remove the old tag or use a naming scheme that includes some
> > @rev marker, both of which are just confusing when talking about tags.
> 
> You're right; when importing incrementally there is no way to know what
> people will do with a tag after the initial conversion.  I was thinking
> more of a one-time conversion.
> 
> If a new tag is created cleanly in subversion (that is, a single copy
> from a single location, then you can read the SVN source (trunk or
> branch name + SVN revision number) directly out of SVN.  A persistent
> look-up table could keep track of the git hashes corresponding to such
> sources.
> 
> If a clean tag is later modified, would it be reasonable to
> "retroactively" create a git branch based on the contents of the old
> tag, and modify that?

That's the first option I described (well, I skipped the "create a
branch" part). But you would get a history like this:

Before the tag change:

 ---A (tag XYZ)
     \
      B---C---D (trunk)

After the tag change:

 ---A---A' (tag XYZ)
     \
      B---C---D (trunk)

So not only does the tag move, but it's also no longer in the history of
trunk. And that makes it IMHO a bit confusing/useless to do that. With
the branches, you at least _know_ that things can change. Tags are not
supposed to do so.

That said, I'd not oppose any optional support to create such tags, I'd
just never use it.

Björn

Re: [Feature Request] Better Subversion integration

[Sebastian Harl]

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

Hi,

On Sun, Feb 10, 2008 at 04:56:11AM +0100, Björn Steinbrink wrote:
> On 2008.02.09 20:44:59 -0600, Sam Granieri Jr wrote:
> > Right now, git-svn import (or clone) will convert tags and branches as  
> > remote branches.
> > I would like it if git could pick up subversion tags and translate them 
> > as git tags upon importing
> 
> SVN tags aren't like git tags. A "tag" in SVN is just another directory,
> which you can modify at will.

Well, a SVN tag could be represented as a Git branch _and_ a Git tag
pointing to the head of that branch. Whenever any such "tag branch"
advances, the user should be notified, the user responsible for the
further commits to the SVN "tag" should be seriously hurt and the Git
tag should be overwritten (git tag -f).

Sam, is that basically what you want?

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Feature Request] Better Subversion integration

[Sam Granieri Jr]

Sebastian,
I think you have the right idea.
One last question
If a person wants to work on a tag branch, would the right idea be to  
create new branch on it as to not screw up the previous tag?

On Feb 11, 2008, at 2:47 AM, Sebastian Harl wrote:

> Hi,
>
> On Sun, Feb 10, 2008 at 04:56:11AM +0100, Björn Steinbrink wrote:
>> On 2008.02.09 20:44:59 -0600, Sam Granieri Jr wrote:
>>> Right now, git-svn import (or clone) will convert tags and  
>>> branches as
>>> remote branches.
>>> I would like it if git could pick up subversion tags and translate  
>>> them
>>> as git tags upon importing
>>
>> SVN tags aren't like git tags. A "tag" in SVN is just another  
>> directory,
>> which you can modify at will.
>
> Well, a SVN tag could be represented as a Git branch _and_ a Git tag
> pointing to the head of that branch. Whenever any such "tag branch"
> advances, the user should be notified, the user responsible for the
> further commits to the SVN "tag" should be seriously hurt and the Git
> tag should be overwritten (git tag -f).
>
> Sam, is that basically what you want?
>
> Cheers,
> Sebastian
>
> -- 
> Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http:// 
> tokkee.org/
>
> Those who would give up Essential Liberty to purchase a little  
> Temporary
> Safety, deserve neither Liberty nor Safety.         -- Benjamin  
> Franklin
>

Re: [Feature Request] Better Subversion integration

[Sebastian Harl]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

Hi Sam,

On Mon, Feb 11, 2008 at 10:55:37AM -0600, Sam Granieri Jr wrote:
> If a person wants to work on a tag branch, would the right idea be to  
> create new branch on it as to not screw up the previous tag?

Why would you want to do that? A tag is supposed to be something
immutable. The only reason for having such a "tag branch" in the first
place is that this seems to be the best representation of what SVN is
doing and there's no better way (yet?) to convert it to something more
Git-like...

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Feature Request] Better Subversion integration

[Jan Hudec]

On Mon, Feb 11, 2008 at 09:47:04 +0100, Sebastian Harl wrote:
> Hi,
> 
> On Sun, Feb 10, 2008 at 04:56:11AM +0100, Björn Steinbrink wrote:
> > SVN tags aren't like git tags. A "tag" in SVN is just another directory,
> > which you can modify at will.
>
> Well, a SVN tag could be represented as a Git branch _and_ a Git tag
> pointing to the head of that branch. Whenever any such "tag branch"
> advances, the user should be notified, the user responsible for the
> further commits to the SVN "tag" should be seriously hurt and the Git
> tag should be overwritten (git tag -f).

There's no need to have a Git _branch_ together with the tag -- tag is also
a ref.

For the rest, the user definitely has to be notified, because git push will
_not_ push out the updated tag if the previous version of it was already
pushed. So the user will have to deal with that manually.

If there was to be a support for tags in git-svn, I would actually suggest to
simply make the name mapping more flexible and simply say, that branches in
tags/ should be imported to refs/tags (while the rest going to
refs/remotes/svn). You see, subversion tags are not annotated (so they don't
need special handling) and git-update-ref will update tags just fine.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>