Re: [tlug] Subversion to Git Conversions

[Curt Sampson <cjs@example.com>]

On 2009-10-28 15:51 +0900 (Wed), Stephen J. Turnbull wrote:

> Curt Sampson writes:
> 
>  > I also think I'm getting a handle on the "remote tracking refs"
>  > that git svn is putting in; I just create head refs on those, right?
> 
> You generally do not want to do that, if I understand what you're
> talking about correctly.  Remote refs need to stay in synch with the
> remote repo, so that should all be handled under the hood.
>
> Of course you can do "git branch <branchname> <remote tracking ref>"
> all you like, if that's what you meant.

That was my exact intent.

The plan I have been experimenting with is to do a "git svn clone" of
the appropriate bit of my svn repo into a bare repo and declare that
the "master" for the moment. However, nobody who clones that master
can see the tracking refs for the branches, right? So I have to create
the branches in the "master" git repo. Then, so long as I have only
commits from that point onward, I can maintain the svn repo in sync by
just doing a "git svn dcommit" on a regular basis, and even continue
to use svn checkouts (so long as they don't commit!). If I have to
roll back after a while, we just all switch back to svn and all is
happy. Otherwise at some point I declare the svn repo to be suitable for
off-line archiving, and take it down.

Does that seem at all sensible?

>  > (By the way, I do realize that a lot of these issues I'm worried
>  > about are caused by svn, not git. But I'm sure you can realize why
>  > anybody without much git experience would be a bit nervous about
>  > commiting years of svn history to it and resolving never to go
>  > back.)
> 
> Even if you were a git expert, you should think twice about that IMO.

Thinking twice about this is precisely what I'm doing now. :-)

> ...Subversion is *much* more reliable, and you don't want to switch
> that until the client requests -- unless there are *really* big
> benefits to offer in return, of course.

I see it as slaying a lot of small-to-moderate annoyances, in trade
for Yet Another VCS Learning Curve. CVS to Subversion was a lot more
tricky than I would guess most developers would think (at least those
who've never done any serious repo administration). With git I have
the advantage of having done this once before, but the disadvantage of
moving to a system that's got much larger differences from the old one.

I think git is mature enough these days that I'm far from the bleeding
edge on this. And I find gitosis, the prospect of much better failover
characteristics, and painless offline operation to be fairly convincing
arguments for git.

(Oh, and did I meantion CHEAP BRANCHING! :-))

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
           Functional programming in all senses of the word:
                   http://www.starling-software.com