Public Git repo

[Derek Atkins]

Yawar Amin <yawar.amin at gmail.com> writes:

> Hi Derek,
>
> On 2011-01-03, at 11:53, Derek Atkins wrote:
>
>>> […]
>> 
>> Apparently there are also issues with importing branches and tags
>> appropriately, as per John's other email.
>
> There is an issue in that git-svn imports branches and tags as remote
> refs (roughly, pointers to the head of a branch). But I’m fairly sure
> I can work around that. I’m running an import right now, following the
> instructions in [1]. I’ll write up a description when I’m sure it
> works.

Okay, so it's a peculiarity of git-svn, not a problem with svn itself.

>>> […]
>> 
>> Do we really have a synchronization problem?  What exactly do you mean
>> by that?
>
> This is something only git-svn users experience. Cloning a large
> remote SVN repository in Git is a long operation. Committing back to
> SVN is also a little tricky in certain situations. A gatekeeper would
> move all that to one point, giving Git users a Git repo that ‘just
> works’. It would collect all Git users’ work. Then someone comfortable
> with the way git-svn works could commit all the collected work into
> the SVN trunk or other branches.

Similarly, this is also a peculiarity of git-svn and not a problem with
svn itself.

>>> […]
>> […]
>> After we get some experience with git and
>> after we'd figured out the proper incantations to completely migrate
>> from svn, then we should *not* work from the gatekeeper repo but instead
>> we should start with a fresh "Master" repo off SVN and make that the
>> "official" repo.
>
> Sure, that’s not a problem. You’ll probably want to do it though, on
> the machine that physically stores the SVN repo, because it is a long
> and bandwidth-intensive operation.

Sure.  If we do decide to move over to git then I'm happy to do the
final conversion locally.  That's why I was asking that good notes be
taken so the process could be repeated.

>>> […]
>> 
>> Is remembering the 'branchy development' really a requirement here?  SVN
>> certainly supports feature and bugfix branches, and we've certainly used
>> it that way.  It does have a problem that you cannot really merge
>> multiple times, so you have to worry about multiple merges from a branch
>> back to trunk.
>
> Multiple merges (or rebases for people doing private work) would
> certainly be very convenient in certain situations.

Of course, but I thought svn-1.6 handles this better?

>>> […]
>> 
>> Here's where I have to question:  does this experimentation have to
>> happen in a way that is easily publically published?  In what way does
>> the status quo not allow this?
>
> That’s a good point. I guess it comes down to how comfortable you are
> with creating and maintaining (i.e. periodically merging in the latest
> changes from trunk) multiple branches in SVN versus in Git. I find Git
> easier, especially the maintaining part.

Sure.  Here's where I have to admit that I've never actually used git.
(Actually, that's not completely true -- I've ran git a couple time to
checkout some code, but the command was copied from the web and run only
once).  Git has been on my list of things I need to look at once I have
the time, but like most everyone it's hard to find that time.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available