Re: [boost] [git] neglected aspects

Subject: Re: [boost] [git] neglected aspects
From: Steven Samuel Cole (steven.samuel.cole_at_[hidden])
Date: 2012-02-11 20:15:19

Rene Rivera wrote:
>> 5. Upload patch to Trac (slow, requires browser, no tool support)
>
> But Trac is globally available across all platforms without having to
> install anything. As is a wide variety of patch application tools.

no matter if svn or git - if you want to do any serious work on a repo, 
you need a locally installed client, don't you ?

>> 7. Apply patch
>
> What happens when the repo you "publish" the patch from goes away before
> anyone has a chance t get it?

it won't.

the new source code is sitting safe and sound in the contributor's 
personal online repository, including its entire development history.

there is only one scenario in which the new source code is unavailable: 
a total internet outage. when was the last time this happened ?

anyway, IF this happens - or simply, if you're offline:

--> under subversion, you're disconnected from the repo, so any 
version-controlled development comes to a grinding halt. If you want to 
keep your changes separate, you're back to creating local copies on your 
harddrive just like back in the 80s before source control was invented.

--> under git, development merrily goes on like nothing happened:
check out, change, diff, commit, revert, etc. with full access to the 
revision history - the only thing you can not do when you're 
disconnected from your repo's origin is push changes back upstream: That 
will have to wait until you're back online.
If you want to work on something else in the meantime and would rather 
not want to mix your changes, create a branch.

 > I.e. how is it different from uploading to
 > a central server like Trac?

In addition to what I said above: Under Subversion, it is correct to 
speak about a 'patch': When new source code is 'delivered', all the 
receiving end sees is one set of files in the state are when they are 
'published' - and the receiver needs to pull it out of trac, so there 
are several gaps in the tool chain.

Under git, the receiver sees an entire repo with the new changes, can 
look through the history of the new development and for example get a 
feel for how often this contributor commits changes, how well they are 
described, how many files are changed per commit, etc.
Also, there is no tool chain gap, all of this happens within one repo - 
and on top of that, git is aware of development history that 2 branches 
have in common, so the receiver does not have figure that out for himself.

As a side effect, this also means that git work can be done in an SSH 
session, whereas in the scenario, trac is required to publish changes 
and that requires a browser which in turn needs a desktop environment.

> But if that's the only advantage.. Does it seem worth it to incur the
> very high cost of switching a central tool? And, yes, I've asked the
> same question (in different words) in just about all the previous svn
> vs. <insert-you-tool-here> threads.

I have worked with Subversion in commercial projects bottom to top for 
5+ years, including set up, administration, dev use, desaster recovery.

After working with git, I have come to the conclusion that upgrading 
from svn to git is worth any effort any time.

In my opinion, boost development is currently slowed down by Subversion 
- and as I said in the OP, this especially concerns welcoming new 
contributors into the project and integrating their contributions in a 
clearly defined and controlled manner.