git for subversion users

git for subversion users

[Patrick Doyle]

Hello all,
I've read http://utsl.gen.nz/talks/git-svn/intro.html, "An
introduction to git-svn for Subversion/SVK users and deserters" and, I
guess I'm looking for a little more information.

It is possible that I am trying to use git and git-svn in a manner for
which they were not designed, so I appreciate any guidance that can be
provided.  Also, since I'm running FC6, I have git version 1.5.0.6
installed, instead of the 1.5.2.2 that I see on the home page.
Perhaps that could be my problem.

Anyway, we have a subversion server set up to track our internal
software development.  I would like to use git/git-svn so that I can
work offline, commit early and often, and occasionally synchronize to
our subversion baseline.  Finally, at least one of our subversion
repositories (my own personal one), is not set up in the traditional
svn://host/repo/{trunk,tags,branches} format.  It is organized as
svn://host/wpd/{project1,project2,project3}.  Since it's my own
personal playground, I don't need branches, and tend to remember tags
just be commit number.

That's the long, boring setup.  Now for the long boring question...

I started playing with a new project over the weekend, checkign in a
handful of commits in git, and now I want to import/export/push/pull
them to the subversion server.

Having read through the tutorial, I started with:

$ svn mkdir svn:///host/wpd/empty-project -m "Created empty project directory"
$ git-svn init svn:///host/wpd/empty-project
$ svn-git fetch

Now I have an empty directory into which I was hoping to "pull" my
changes from my weekend playground

$ git pull ~/playground/new-project
... (I get 7 new files, and, it looks like, their associated history)

Here's where I get stuck...
1) How can I remind myself of what I changed relative to what was in
the Subversion repository the last time I sync'd to it?  Under my
current model of operation, I come in after a weekend/night away, do
"svn status" and "svn diff" to remind myself what's changed, and
commit those changes with appropriate log messages.  I am hoping that
I can make the changes locally, commiting them with nice log messages
as I make the changes, and then "push" them to the subversion server
when convenient.

2) This is going to have some obvious problems when I work on other
projects shared with other developers.  We know how to address this
with Subversion (good communication, updating the working copy prior
to a commit, resolving the minor conflicts, etc...) what can I expect
when my local repository is git?

3) If I try to commit my change with:

$ git-svn dcommit

I get an error
Commit 0e3e....
has no parent commit, and therefore nothing to diff against.
You should be working from a repository originally created by git-svn

and that's where I get confused.  Is this a bug/feature of 1.5.0.2
that will disappear if I switched to 1.5.2.2?

Are there any other tips/resources for mixed mode operation
(centralized Subversion server, distributed git client(s))?

Thanks for any pointers.

--wpd

Re: git for subversion users

[Sam Vilain]

Patrick Doyle wrote:
> Hello all,
> I've read http://utsl.gen.nz/talks/git-svn/intro.html, "An
> introduction to git-svn for Subversion/SVK users and deserters" and, I
> guess I'm looking for a little more information.
  [...]
> svn://host/wpd/{project1,project2,project3}.  Since it's my own
> personal playground, I don't need branches, and tend to remember tags
> just be commit number.

There's your first issue - misunderstanding branching :)  You should end
up realising that every little idea or feature forms a code branch in
the direction of its implementation, the choice is whether to let the
branches twist and grow together or train them in clear directions.

> Here's where I get stuck...
> 1) How can I remind myself of what I changed relative to what was in
> the Subversion repository the last time I sync'd to it?  Under my
> current model of operation, I come in after a weekend/night away, do
> "svn status" and "svn diff" to remind myself what's changed, and
> commit those changes with appropriate log messages.  I am hoping that
> I can make the changes locally, commiting them with nice log messages
> as I make the changes, and then "push" them to the subversion server
> when convenient.

use git-branch -a to show you the name that the remote subversion branch
is set up on.

then you can use "git-diff svn/trunk" (say, if it listed it as
"svn/trunk") to show you the files changed between your working copy and
the last subversion commit you did.

I can see that this point isn't very clear from the tutorial if you go
straight in at "How to ... commit back to Subversion".  That section
needs a bit of an overall introduction I think.  The idea is that first,
you make the changes in your local branch. (see
http://utsl.gen.nz/talks/git-svn/intro.html#local-commit).  Then you use
dcommit to save it to Subversion.  Using this you can stage multiple
commits, and if you don't like them you can go back and review them
before they are set in SVN forever.

That mode of operation is already natural for SVK users which the
tutorial was primarily targeted at - so they were probably already
looking for information on how to create a local branch, make local
changes and then push back.

> 2) This is going to have some obvious problems when I work on other
> projects shared with other developers.  We know how to address this
> with Subversion (good communication, updating the working copy prior
> to a commit, resolving the minor conflicts, etc...) what can I expect
> when my local repository is git?

If svn is still the master there should be no difference to the way you
normally collaborate development using Subversion.  The central server
is still the publishing point for trunk, however many release
engineering branches you use, and feature branches.  It's only if you
want to start mixing groups of people, some working with subversion, and
other people using git-svn and merging between each other at the git
level, that you can start getting confused.  They can safely operate at
the patch trading level though.

> 3) If I try to commit my change with:
> 
> $ git-svn dcommit
> 
> I get an error
> Commit 0e3e....
> has no parent commit, and therefore nothing to diff against.
> You should be working from a repository originally created by git-svn
> 
> and that's where I get confused.  Is this a bug/feature of 1.5.0.2
> that will disappear if I switched to 1.5.2.2?
> 
> Are there any other tips/resources for mixed mode operation
> (centralized Subversion server, distributed git client(s))?

Almost certainly because you haven't committed locally yet.

Sam.

> 
> Thanks for any pointers.
> 
> --wpd
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git for subversion users

[Steven Grimm]

Sam Vilain wrote:
> If svn is still the master there should be no difference to the way you
> normally collaborate development using Subversion.  The central server
> is still the publishing point for trunk, however many release
> engineering branches you use, and feature branches.  It's only if you
> want to start mixing groups of people, some working with subversion, and
> other people using git-svn and merging between each other at the git
> level, that you can start getting confused.  They can safely operate at
> the patch trading level though.
>   

I can vouch for all of that as well. On some of my repositories I use 
git solely as a fancy Subversion client, no interaction with any other 
git repositories. And hardly anyone at my company even knows about it; 
as far as they are concerned I just check stuff into the svn repository 
like any other engineer.

But on a few of my repositories I do things like use git to keep a copy 
of my work in progress synced up between my laptop and my development 
server, or (rarely) share my work with another git-aware developer. In 
those cases I do have to be kind of careful what I do, mostly around 
making sure all the repositories are in agreement about which branches 
come from where and about when I use rebase vs. merge vs. squash merge.

I will say, though, that the upcoming addition to git-svn to allow 
merges to be directly committed to the svn repository will make some of 
those kinds of scenarios a lot less brittle than they are now. It's 
still a work in progress but it looks very promising so far. (Search the 
list for "[PATCH] git-svn: allow dcommit to retain local merge 
information" if you want to see what I'm talking about.)

-Steve

Re: git for subversion users

[Sam Vilain]

Steven Grimm wrote:
> I will say, though, that the upcoming addition to git-svn to allow 
> merges to be directly committed to the svn repository will make some of 
> those kinds of scenarios a lot less brittle than they are now. It's 
> still a work in progress but it looks very promising so far. (Search the 
> list for "[PATCH] git-svn: allow dcommit to retain local merge 
> information" if you want to see what I'm talking about.)

Yes.  On that.  It would be nice if git-svn could also fake setting
remote merge properties, too.

Some beginnings at:

  http://git.catalyst.net.nz/gw?p=git.git;a=shortlog;h=svk-merge
  (pull from git://git.catalyst.net.nz/git.git#svk-merge)

What it needs to do;

  0. preserve the notion that commits tagged with "git-svn-id:" should
     not vary depending on who synced them.

  1. on commit, if we're committing a merge, make sure that the other
     parent has the same revision somewhere in the repo, and then set
     the "svk:merge" and "svnmerge-integrated" tags to accurately record
     which parent SVN revisions are used

  2. when fetching revisions, spot these tickets and set parents
     appropriately.  In the case of SVK, the merge tickets may
     correspond to revisions in (inaccessible) svk local depots.  It may
     be possible to infer these extra parents in some limited
     situations using the extra information svk puts in commit messages
     by default, but I doubt that is a useful endeavour!

I'll take a look at what you've been working on and see if that's not
what you're already trying...

Sam.

Re: git for subversion users

[Sam Vilain]

Sam Vilain wrote:
> It would be nice if git-svn could also fake setting
> remote merge properties, too.
> 
> Some beginnings at:
> 
>   http://git.catalyst.net.nz/gw?p=git.git;a=shortlog;h=svk-merge
>   (pull from git://git.catalyst.net.nz/git.git#svk-merge)
> 
> What it needs to do;
> 
>   0. preserve the notion that commits tagged with "git-svn-id:" should
>      not vary depending on who synced them.
> 
>   1. on commit, if we're committing a merge, make sure that the other
>      parent has the same revision somewhere in the repo, and then set
>      the "svk:merge" and "svnmerge-integrated" tags to accurately record
>      which parent SVN revisions are used
> 
>   2. when fetching revisions, spot these tickets and set parents
>      appropriately.

Proof of concept for #2 at:

http://git.catalyst.net.nz/gw?p=git.git;a=commitdiff;h=816e2ef

Sam.

Re: git for subversion users

[Patrick Doyle]

Thank you all for the tips and pointers,  especially to Sam, who has
given me something to digest, and to Steven, whose mode of operation,
"I can vouch for all of that as well. On some of my repositories I use
git solely as a fancy Subversion client, no interaction with any other
git repositories. And hardly anyone at my company even knows about
it"; precisely matches what I am trying to do.

It seems that a large part of my original problem was with the fact
that FC6 only has git-1.5.0.2 on it.  When I installed 1.5.2.2, things
started working much more smoothly for me.

I still have one issue... say I start a project in git and later want
to publish it to the subversion server, history and all... how do I do
that?

Right now, I do the following:

$ svn mkdir url://to/svn/repo/newproject -m "made directory"
$ git-svn clone url://to/svn/repo/newproject
$ cd newproject
$ git pull url://from/project/started/in/git
$ git log
-- shows the history of my git based project, along with the "made
directory" log message
$ git-svn dcommit
-- commits only a single change to the svn repository with a log
message that reads something like "merged
url://from/project/started/in/git"
$ git-log
-- no longer shows the history of my git based project, it just shows
the subversion history

Is this related to the follow-on discussion regarding handling merges properly?

Is there some other way to "export" a git repository to a subversion
repository, maintaining the history along the way?

Once again, thanks for your help.

--wpd

Re: git for subversion users

[Alexander Litvinov]

В сообщении от 26 июня 2007 11:33 Sam Vilain написал(a):
> There's your first issue - misunderstanding branching :)  You should end
> up realising that every little idea or feature forms a code branch in
> the direction of its implementation, the choice is whether to let the
> branches twist and grow together or train them in clear directions.

git-svn has one major trouble with branch handling: merge two branches that 
are different branches at svn. Or simply start from different point from svn 
branch.

git-svn dcommit operation tries to figure out where to commit at svn side and 
fail at these conditions. It seems to me this happend becuse it uses special 
line at git's commit comment and in case of such merge it does not know there 
to commit. I did not found how to deal with this situation.

So, git-svn just a offline-capable version of svn client with linear history. 
Sure. you can fork your own branch and then merge it into svn branch again 
but you should really careful about this.

I even does not know the way to solve this problem.

---
Alexander Litvinov.

subversion and merging [was: Re: git for subversion users]

[Sam Vilain]

Alexander Litvinov wrote:
> So, git-svn just a offline-capable version of svn client with linear history. 
> Sure. you can fork your own branch and then merge it into svn branch again 
> but you should really careful about this.
> 
> I even does not know the way to solve this problem.

The problem is the SVN model.  Only now that people have woken up en
masse to the fact that tracking merges is actually really important are
they adding it to the core.

Their system¹ is of course completely incompatible with the predominant
tool for this SVK (no complaints there).  Thankfully it looks based on
the other major solution out there, svnmerge, so hopefully only minor
incompatibilities can be expected.

My first analysis of the solution is that they have approached this on
two levels: commit merge ancestry and file merge ancestry.

File merge ancestry, while central to tools like Perforce, is a pretty
alien concept to git and almost certainly can be derived (probably more
reliably in practice) using git-cherry-type algorithms.  I describe this
as the "smash patches to pieces" development model on my git-svn tutorial.

Commit merge ancestry is however a basic feature in git.  They are even
going further than that and allowing cherry picks to be tracked as well.
 This information is currently derived in git using git-cherry.

Sam.

¹ http://subversion.tigris.org/merge-tracking/design.html