Subject: Re: git for subversion users

From: Sam Vilain <[email-masked]>
Date: Tue, 26 Jun 2007 16:33:55 +1200

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 [email-masked]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html