Public Git repo

[Yawar Amin]

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.

>> […]
> 
> 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.

>> […]
> […]
> 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.

>> […]
> 
> 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.

>> […]
> 
> 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.

>> […]
> […]
> you still have to manually
> deal with code divergence..  And that is really the hard part of
> merging.
> […]

Sure, merge conflicts are hard for every VCS, because they’re a human/social problem. Not a technical one.

> […]
> 
>>   OpenPGP signatures on tagged commits. SHA1
>> verification of repo integrity (tamper-proofing, malicious intent or
>> otherwise). Built-in author attribution–Git records both who authored
>> the patch and who committed it to the repo. And, not directly a Git
> 
> I don't think these features matter all that much, do they?

SHA1 repo integrity is very cool because all your repo backups (clones) spread out across the internet can be verified just by checking that a single SHA1 sum (say, that of the latest tagged release) matches a known-good SHA1.

>> […]
> 
> I think any system has its own archana.  It's all a question of what
> you're used to and what you know.  Learning a new system always takes
> time.

True.

>> […]
> 
> See, you should look into svk!  SVK provides many of the features you're
> asking about.

I’ll look into it one of these days but a little swamped right now with work stuff :-)

Regards,

Yawar

[1] http://oreilly.com/catalog/9780596520137/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20110104/60a58762/attachment.bin>