git for subversion users

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

Patrick Doyle wrote:

  [...]

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.

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.

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.

Almost certainly because you haven't committed locally yet.

Sam.

Sam Vilain wrote:

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

Steven Grimm wrote:

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.

Sam Vilain wrote:

Proof of concept for #2 at:

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

Sam.

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

В сообщении от 26 июня 2007 11:33 Sam Vilain написал(a):

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.

Alexander Litvinov wrote:

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