[git] neglected aspects

[Steven Samuel Cole]

Hi all,

First post here, so please bear with me.

A lot has been said in the last year on the subject of a possible
migration from svn to git. However, after reading pretty much every
message on the issue on this list (sic!), I have the impression that
some of the most important aspects did not get the consideration they
require. I would therefore like to add my outside perspective.


SUMMARY:

1. an svn --> git migration does cause some major, but one-time
disruption. However, svn right now causes minor, but continuous
disruption on a daily basis - which often goes unnoticed.

2. git's distributed concept is nothing less than one generation ahead
of centralized VCSs like svn. The benefits usually do not become
apparent until git is actually used in practice.

3. at the moment, boost is significantly missing out on fresh enthusiasm
that new contributors could bring into the project; svn and the policies
it mandates are partly too blame for that.

4. svn trunk (i.e. boost library) maintainers are too limited by the svn
concept in their decision which changes they merge at what point in time
and may be pressured into rushing suboptimal decisions; this can make
maintenance work painful and frustrating. git greatly alleviates that
problem.

5. IMO, it's not 'if', it is 'when'. The longer a migration is delayed,
the longer boost development will be slowed down without even noticing.


DETAILS:

I am aware that some of my points technically are mentioned on the boost
git wiki page at https://svn.boost.org/trac/boost/wiki/Git/WhyGit, but
they still seem somewhat neglected. This is probably not surprising as
many participants in the discussion
1. presumably are established boost contributors and thus share a
    'from the inside' view of the subject and
2. are only marginally affected by svn's conceptual problems


This is what happened here in the last couple of days:

I needed a tool for a job in my current project and I couldn't find one,
so I thought about what components I need to build my own. A little web
research - Boost.Iostreams looks perfect for the purpose.

You have all been through what comes next, be it with boost or with
other open source software: Download the latest release, install the
libraries, start reading the docs, run some sample code, etc.

While reading, I spot a typo in an HTML doc, then another in an include
file comment, a third one in another file... the fourth one at the
latest makes me think - this is open source, I should sync the latest
sources, fix all those typos as I come across them while reading and
contribute them back to the project.

A quick read on submitting bugs on boost.org, svn co yadi yadi, fix the
typos locally. Of course I don't have write privileges to the repo, so
the best I can do for now is create a patch and attach that to a bug
report. Within minutes, someone takes care of the bug, comments and
takes ownership. Excellent! Smithers, money fight!

I go back to reading, find more typos. My patch has not been committed
to the trunk yet, so my local changes are still sitting there on my
local hard drive. If I do another svn diff > file_2.patch, the patch
will also contain the changes I have already attached to the bug report.

What are my options now ? Revert my changes, base the new ones on the
head revision and send another patch ? Create a new patch file and
manually remove the diffs of the old changes I already sent ? How will
the upstream maintainer know which changes are based on what version ?

Also, I notice a few other things that in my opinion could be done
better to facilitate adoption of the iostreams library. I would be
willing to do the work and I would in the perfect position as I am
walking in the shoes of an adopter right now - but these are separate
from the typo fixes and they are larger issues; considering I can't
check my changes in, would I really want to have them sit on my local
harddrive, waiting possibly for months for someone upstream to review
and hopefully merge them ?


A couple of hours later: I get an email from boost bugs/svn; the
upstream maintainer has committed my changes. However, I actually
receive not one, but two emails, because the upstream guy chose to split
my patch into changes on documentation and changes on source code (which
presumably required extra work on his part).

I do an svn up and now have to deal with conflicts between my local
changes and the new commits: I make a note of my second set of changes
and overwrite my local files with the new repo versions, then bring the
second set back in.

Uff! That's a lot of work just to fix some typos! And these are just
cosmetic issues in discrete chunks that do not require any testing;
contributing changes to source code would take even more effort and more
caution - build and test on several platforms, peer review, etc.

Also, the upstream maintainer jumped on the bug report right away and
integrated my changes within hours. This is the ideal situation (thanks
again Daniel, great job! :-) - usually, things don't happen so quickly -
especially around major release time.


HOW THIS IS DONE IN GIT:

1. google 'github iostreams'
    --> click first search result: https://github.com/boost-lib/iostreams
    (this can be even reduced to 'gh: iostreams' by integrating github
    into chrome search engines, but that's another story...)

2. on githup website, click 'fork', wait a few seconds
    --> this auto-creates my personal online github iostreams repo

3. on my local machine, open a shell, enter 'git clone ', copy & paste
    the repo .git url shown on the website in there and run e.g.
    'git clone [hidden email]:<username>/iostreams.git'
    --> this creates a local fork of my personal online iostreams repo
    + the mailing list probably changes the line above to 'hidden'
    + there is github/desktop integration and a plethora of gui clients

4. i change local files and commit to the local repo. once a set of
    changes is complete, i push them online into my personal online
    repo; once my work has reached some maturity, I send a pull request
    to the upstream maintainer of the official iostreams repo, aka
    the keeper of the trunk.

disclaimer: I have omitted one-time steps to set up local git,
github.com account, ssh keys, lastpass integration, yadi yadi.
these steps are abundantly documented online, done in minutes and
required only once.


THE GIT ADVANTAGE:

I don't have to wait for the first set of changes to be merged into
the trunk before I resync, resolve conflicts and base the second
set on the new head revision; I simply create a new branch for
a new change set and send a new pull request once my work is complete.

The upstream maintainer has no peer pressure to merge any changes in:
He/she is sitting on the head revision and is looking at a number of
pull requests for change sets in various personal forks like mine; these
are more like 'change offers' the maintainer is free to merge in if
he/she so chooses (cherry-picking) - or postpone if this is not the time
because for example a major release is due and they seem too risky.

I as a contributor do not really care so much: Of course I am stoked if
my work actually makes it into the project eventually, but the point in
time when this happens technically does not matter to me - pending
changes will not get in my way if the merge takes a little longer.


This is the major difference between svn and git - and I can not stress
this advantage enough: I am decoupled from, but still connected to the
official trunk. I can make arbitrary changes and group them in any way I
see fit. I offer them to upstream and move on to new development.

As a side effect, this also provides an overview impression of quality
and continuity of the work of a potential new contributor.

Of course it is technically correct that svn also supports the concepts
of forks and branches, but in terms of tooling and mentality, they are
considered much more heavy-weight than in git and might get created a
couple of times a year - while in git, they might come and go a couple
of times a day.


Finally, the 'series of tubes' metaphor IMO does not really hit it.
Subversion to me seems more like a freight train where the waggons move
at different speeds, so they constantly bump into the car behind and in
front of them; movement of the entire train is jerky.
Git on the other hand is a bunch of space ships linked by hyperelastic
tractor beams: Even if one travels out as far as the delta quadrant, the
upstream connection will always make sure the collective does benefit
from any new development it brings back from there.


[snipped several paragraphs about cultural and other aspects; maybe some
other time.]


# ssc

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Olaf van der Spek-3]

On Wed, Feb 8, 2012 at 7:30 AM, Steven Samuel Cole
<[hidden email]> wrote:
> ...

I've never used git, but I have used bzr. Having worked with a dvcs,
the disadvantages of svn become quite clear. Svn *might* be fine for
personal (one dev) projects, but for bigger projects it's just not the
right option.

I can't think of any real downsides.

--
Olaf

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Julian Gonggrijp]

Olaf van der Spek wrote:

> On Wed, Feb 8, 2012 at 7:30 AM, Steven Samuel Cole
> <[hidden email]> wrote:
>> ...
>
> I've never used git, but I have used bzr. Having worked with a dvcs,
> the disadvantages of svn become quite clear. Svn *might* be fine for
> personal (one dev) projects, but for bigger projects it's just not the
> right option.
>
> I can't think of any real downsides.

I found out that John Wiegley has been working on a faithful
conversion of the boost svn tree to git, see [1]. Is that effort still
ongoing?

Also, there has been a very interesting discussion on branching model
and release process, which seems to have started with [2]. Two
subthreads particularly interested me, i.e. the one starting in [3]
and another one starting just before [4] (especially the dialogue
between Vladimir Prus and Dave Abrahams).
This might have been mentioned before, but gitflow seems to be ideal.
See [5] for an explanation of the branching model and [6] for an
optional tool which automates workflows that adopt the model.

-Julian

1. http://lists.boost.org/Archives/boost/2011/01/176378.php
2. http://lists.boost.org/Archives/boost/2011/01/176002.php
3. http://lists.boost.org/Archives/boost/2011/01/176245.php
4. http://lists.boost.org/Archives/boost/2011/01/176226.php
5. http://nvie.com/posts/a-successful-git-branching-model/
6. https://github.com/nvie/gitflow


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Beman Dawes]

On Wed, Feb 8, 2012 at 1:30 AM, Steven Samuel Cole
<[hidden email]> wrote:

> ... extensive description of Git and its advantages to Boost.

I've become a firm believer in the advantages of Git, both for my
personal projects and for larger projects.  I believe Boost should
move to Git sooner rather than later.

I've proposed a BoostCon/C++Now tutorial and workshop on moving Boost
to Git. The Steering Committee will be meeting, so perhaps we can get
a go ahead for Git!

Thanks to Steven for his informative and timely post!

--Beman

PS: FWIW, the C++ committee is now using Git (via GitHub) for the
working paper and other documents.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Thomas Heller-7]

On 02/08/2012 07:30 AM, Steven Samuel Cole wrote:

> Hi all,
>
> First post here, so please bear with me.
>
> A lot has been said in the last year on the subject of a possible
> migration from svn to git. However, after reading pretty much every
> message on the issue on this list (sic!), I have the impression that
> some of the most important aspects did not get the consideration they
> require. I would therefore like to add my outside perspective.
>

Thanks for your comments.

> SUMMARY:
>
> 1. an svn --> git migration does cause some major, but one-time
> disruption. However, svn right now causes minor, but continuous
> disruption on a daily basis - which often goes unnoticed.
>
> 2. git's distributed concept is nothing less than one generation ahead
> of centralized VCSs like svn. The benefits usually do not become
> apparent until git is actually used in practice.
>
> 3. at the moment, boost is significantly missing out on fresh enthusiasm
> that new contributors could bring into the project; svn and the policies
> it mandates are partly too blame for that.
>
> 4. svn trunk (i.e. boost library) maintainers are too limited by the svn
> concept in their decision which changes they merge at what point in time
> and may be pressured into rushing suboptimal decisions; this can make
> maintenance work painful and frustrating. git greatly alleviates that
> problem.
>
> 5. IMO, it's not 'if', it is 'when'. The longer a migration is delayed,
> the longer boost development will be slowed down without even noticing.

<snip>
> This is what happened here in the last couple of days:

Now let's play the same game with git.

> I needed a tool for a job in my current project and I couldn't find one,
> so I thought about what components I need to build my own. A little web
> research - Boost.Iostreams looks perfect for the purpose.
>
> You have all been through what comes next, be it with boost or with
> other open source software: Download the latest release, install the
> libraries, start reading the docs, run some sample code, etc.
>
> While reading, I spot a typo in an HTML doc, then another in an include
> file comment, a third one in another file... the fourth one at the
> latest makes me think - this is open source, I should sync the latest
> sources, fix all those typos as I come across them while reading and
> contribute them back to the project.

Nothing really changes here.

> A quick read on submitting bugs on boost.org, svn co yadi yadi, fix the
> typos locally. Of course I don't have write privileges to the repo, so
> the best I can do for now is create a patch and attach that to a bug
> report. Within minutes, someone takes care of the bug, comments and
> takes ownership. Excellent! Smithers, money fight!

Great! Now with something like github you create your own fork, push to
that and eventually create a pull request and wait until it gets applied
... as you described. The process didn't change. You just named the
steps differently.

> I go back to reading, find more typos. My patch has not been committed
> to the trunk yet, so my local changes are still sitting there on my
> local hard drive. If I do another svn diff > file_2.patch, the patch
> will also contain the changes I have already attached to the bug report.
>
> What are my options now ? Revert my changes, base the new ones on the
> head revision and send another patch ? Create a new patch file and
> manually remove the diffs of the old changes I already sent ? How will
> the upstream maintainer know which changes are based on what version ?

Simple. Update the bug you already filed with the patch containing all
fixes. What would be the options with git? Update the pull request?
Again, same thing, different name.

> Also, I notice a few other things that in my opinion could be done
> better to facilitate adoption of the iostreams library. I would be
> willing to do the work and I would in the perfect position as I am
> walking in the shoes of an adopter right now - but these are separate
> from the typo fixes and they are larger issues; considering I can't
> check my changes in, would I really want to have them sit on my local
> harddrive, waiting possibly for months for someone upstream to review
> and hopefully merge them ?

So with git you pushed them to your personal fork. Over time, your fork
and the upstream version eventually diverge. You have to maintain your
changes. Same thing when the changes lurk on your local svn working.

> A couple of hours later: I get an email from boost bugs/svn; the
> upstream maintainer has committed my changes. However, I actually
> receive not one, but two emails, because the upstream guy chose to split
> my patch into changes on documentation and changes on source code (which
> presumably required extra work on his part).

Frankly, I don't see how this would change with git.

> I do an svn up and now have to deal with conflicts between my local
> changes and the new commits: I make a note of my second set of changes
> and overwrite my local files with the new repo versions, then bring the
> second set back in.

Same again. How is this significantly different to what you'd do with git?

> Uff! That's a lot of work just to fix some typos! And these are just
> cosmetic issues in discrete chunks that do not require any testing;
> contributing changes to source code would take even more effort and more
> caution - build and test on several platforms, peer review, etc.

Right, all that wouldn't change with having git as the tool of choice.

> Also, the upstream maintainer jumped on the bug report right away and
> integrated my changes within hours. This is the ideal situation (thanks
> again Daniel, great job! :-) - usually, things don't happen so quickly -
> especially around major release time.

Right, and that won't change with git. Or do I miss an essential point?

<snip>

> THE GIT ADVANTAGE:
>
> I don't have to wait for the first set of changes to be merged into
> the trunk before I resync, resolve conflicts and base the second
> set on the new head revision; I simply create a new branch for
> a new change set and send a new pull request once my work is complete.

Errm ... you can still do that with svn. just continue working. Make a
new patch, update the patch in the bug report you filed, yes trac can do
that. There really is no need to wait for anything.

> The upstream maintainer has no peer pressure to merge any changes in:
> He/she is sitting on the head revision and is looking at a number of
> pull requests for change sets in various personal forks like mine; these
> are more like 'change offers' the maintainer is free to merge in if
> he/she so chooses (cherry-picking) - or postpone if this is not the time
> because for example a major release is due and they seem too risky.

So, how is it really different from the current trac system?

> I as a contributor do not really care so much: Of course I am stoked if
> my work actually makes it into the project eventually, but the point in
> time when this happens technically does not matter to me - pending
> changes will not get in my way if the merge takes a little longer.
>
> This is the major difference between svn and git - and I can not stress
> this advantage enough: I am decoupled from, but still connected to the
> official trunk. I can make arbitrary changes and group them in any way I
> see fit. I offer them to upstream and move on to new development.

I think i miss something fundamental here.

While there are shortcomings in the current process, they won't be
solved by changing tools.

Just my 0.02€. Sorry to be the party pooper ...

Regards,
Thomas

P.S: I find it way harder to properly maintain a couple of git branches
and forks than doing my stuff with svn. The git userinterface is just a
pain, i regularly get confused and have no idea what to do.

P.P.S: The only real advantage I see in DVCSs is the better local
working copy managing, as in you can create local branches, commiting
locally etc. but while having dismissed git in favor of svn for a while
now, I didn't really miss these particular features.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Brian Schrom-2]

On 02/08/2012 08:57 AM, Thomas Heller wrote:
> P.S: I find it way harder to properly maintain a couple of git branches
> and forks than doing my stuff with svn. The git userinterface is just a
> pain, i regularly get confused and have no idea what to do.

When I first started using git, from being very comfortable with svn, it
was very frustrating for me.  The things that got me past the
frustration and onto reasonable work flows were gitk, git gui, and git
stash.

gitk is a GUI that shows the branches, commits, etc
git gui shows working copy/branch things, commits.  Amending last commit
and cherry picking are a great features built into gui.
git stash is a stack of patches

I started using git via git-svn which complicates things because of the
necessity to commit back to svn properly.

git fetch
git svn rebase
git stash

are essential commands to know about to work with git-svn

The upshot is, the initial learning curve, especially if coming from a
cvs/svn background, is nonzero.  One of my favorite quotes is that
"learning to use c++/Unix/(now Git)" is hard, but using c++/Unix/git is
easy."  My opinion, the time investment in all of these tools will repay
you 100 fold.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Tim Blechmann-2]

> > Also, I notice a few other things that in my opinion could be done
> > better to facilitate adoption of the iostreams library. I would be
> > willing to do the work and I would in the perfect position as I am
> > walking in the shoes of an adopter right now - but these are separate
> > from the typo fixes and they are larger issues; considering I can't
> > check my changes in, would I really want to have them sit on my local
> > harddrive, waiting possibly for months for someone upstream to review
> > and hopefully merge them ?
>
> So with git you pushed them to your personal fork. Over time, your fork
> and the upstream version eventually diverge. You have to maintain your
> changes. Same thing when the changes lurk on your local svn working.

well, your svn working copy is just a bunch of files, while git's personal
branches are part of the repository ... you can merge, rebase, stash, etc ...
with svn your working copy gets easily out of sync ...
the nice thing of git is that it does not really harm if your branch diverges
from upstream, as its merge facilities are much more sophisticated than
everything that subversion has to offer ...

frankly, since i moved my code into boost's svn, i find it way more fragile to
maintain than before

tim


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Øivind Loe]

Hi all,

I share the views of Steven. I have worked with svn for a couple of
years, but for the last 4 years I have been using git every day at
work.

One of GITs strengths is how easy it is to keep branches in sync.
Collaboration is in my opinion a lot easier compared with SVN.

Being able to create commits in a local repository, then push these
commits upstream rather than pushing a patch makes your local GIT
checkout able to know where it is when these fixes have been included
upstream and you want to pull the changes. Generally, very little
manual merging necessary.

As Steven also said, the upstream maintainer can cherry-pick just the
changes he wants to include. As long as a change in the local git repo
is contained in one or more commits, the upstream maintainer can
cherry-pick this/these commits into the upstream repo. Even after
this, syncing back to the local repo is no problem.

The only downside (I can see) with GIT is that it has a bit of a learning curve.

-Øivind

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Thomas Heller-7]

On 02/08/2012 06:29 PM, Tim Blechmann wrote:

>>> Also, I notice a few other things that in my opinion could be done
>>> better to facilitate adoption of the iostreams library. I would be
>>> willing to do the work and I would in the perfect position as I am
>>> walking in the shoes of an adopter right now - but these are separate
>>> from the typo fixes and they are larger issues; considering I can't
>>> check my changes in, would I really want to have them sit on my local
>>> harddrive, waiting possibly for months for someone upstream to review
>>> and hopefully merge them ?
>>
>> So with git you pushed them to your personal fork. Over time, your fork
>> and the upstream version eventually diverge. You have to maintain your
>> changes. Same thing when the changes lurk on your local svn working.
>
> well, your svn working copy is just a bunch of files, while git's personal
> branches are part of the repository ... you can merge, rebase, stash, etc ...

Right, you have those. Now what's left is to know when to use what, etc.

> with svn your working copy gets easily out of sync ...

svn update is all you need. ever. There are conflicts from time to time.
Man up resolve them.

> the nice thing of git is that it does not really harm if your branch diverges
> from upstream, as its merge facilities are much more sophisticated than
> everything that subversion has to offer ...

I've heard that a couple of times now. My personal experience with git
however is quite the contrary. I regularly mess up my local repository.

> frankly, since i moved my code into boost's svn, i find it way more fragile to
> maintain than before

Yes, I used to advertise git too. I had the exact same experience. That
goes away. After a while, you won't look back to git, and enjoy "svn up"
and "svn commit" and start to question the usefulness of decentralized
version control systems for a centralized boost altogether.

> tim
>
>
> _______________________________________________
> Unsubscribe&  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Michael Caisse-2]

On 2/8/2012 9:29 AM, Tim Blechmann wrote:

>>> Also, I notice a few other things that in my opinion could be done
>>> better to facilitate adoption of the iostreams library. I would be
>>> willing to do the work and I would in the perfect position as I am
>>> walking in the shoes of an adopter right now - but these are separate
>>> from the typo fixes and they are larger issues; considering I can't
>>> check my changes in, would I really want to have them sit on my local
>>> harddrive, waiting possibly for months for someone upstream to review
>>> and hopefully merge them ?
>>
>> So with git you pushed them to your personal fork. Over time, your fork
>> and the upstream version eventually diverge. You have to maintain your
>> changes. Same thing when the changes lurk on your local svn working.
>
> well, your svn working copy is just a bunch of files, while git's personal
> branches are part of the repository ... you can merge, rebase, stash, etc ...
> with svn your working copy gets easily out of sync ...
> the nice thing of git is that it does not really harm if your branch diverges
> from upstream, as its merge facilities are much more sophisticated than
> everything that subversion has to offer ...
>
> frankly, since i moved my code into boost's svn, i find it way more fragile to
> maintain than before
>
> tim
>

Hi Tim -

I am interested in your views here. I have had good success with git and
monolithic projects. How would you go about working on your library and
then pushing to the central repo. Would you envision that the central
repo is nothing more than a shell pointing to submodules that are the
"real" library repos? Or would you just rebase all of boost before
committing back modifications to your library? Or some other process
completely?

I'm sure people have thought about this problem and the solutions. You
might be one of them. Unfortunately I mostly hear how great it would be
to move to git but few have provided the usage for a project like boost
: a loosely coupled and independently developed collection of libraries.

Thanks!
michael


--

----------------------------------
Michael Caisse
Object Modeling Designs
www.objectmodelingdesigns.com


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Daniel James-3]

On 8 February 2012 14:37, Julian Gonggrijp <[hidden email]> wrote:
>
> This might have been mentioned before, but gitflow seems to be ideal.
> See [5] for an explanation of the branching model and [6] for an
> optional tool which automates workflows that adopt the model.

The problem that we face with something like gitflow is testing. We
only have the infrastructure for testing two branches so we can't
adequately test feature branches. We really do need to test on a wide
variety of platforms as early as possible. But we wouldn't want to
merge half done features into the develop branch just to get testing
(this is one of the biggest problems we have at the moment, changes
are often in trunk for some time before they're merged into release,
if at all).

A possible solution would be to use the 'develop' branch as the
equivalent of our current release branch (I'm not sure how to branch
for release, we might have to do without and just restrict additions
to develop as we currently do, at least at first) and add another
'testing' branch. This would branch from develop, and feature branches
would be merged into it for testing. Once testing has shown the
feature branch seems to be release worthy, it would be merged into
develop. The testing branch would never be merged into anything (its
history would be very messy). We would probably create a new testing
branch regularly (once per release cycle?) so that neglected features
would be dropped.

Or maybe, rather than being a traditional branch, the test repo could
be created by a script which merges in active feature branches. It'd
have to deal with conflicts though, maybe just keeping track of
commits that are known to be good and sticking with them when a
conflict is found. But something like that could be developed later -
especially after having some experience of how the process works.

This testing mechanism would be fairly separate from the main flow
structure so it could be provided by an additional tool to gitflow.
Hopefully wouldn't be too hard to develop. Does that make any sense? I
know it isn't ideal, but it seems plausible given our current
infrastructure. And we could work on improving it as we go.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Olaf van der Spek-3]

On Wed, Feb 8, 2012 at 7:35 PM, Michael Caisse
<[hidden email]> wrote:
> I'm sure people have thought about this problem and the solutions. You might
> be one of them. Unfortunately I mostly hear how great it would be to move to
> git but few have provided the usage for a project like boost : a loosely
> coupled and independently developed collection of libraries.

Maybe that's because most people see value in git that's unrelated to
(supporting) decoupling.

--
Olaf

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Michael Caisse-2]

On 2/8/2012 11:40 AM, Olaf van der Spek wrote:

> On Wed, Feb 8, 2012 at 7:35 PM, Michael Caisse
> <[hidden email]>  wrote:
>> I'm sure people have thought about this problem and the solutions. You might
>> be one of them. Unfortunately I mostly hear how great it would be to move to
>> git but few have provided the usage for a project like boost : a loosely
>> coupled and independently developed collection of libraries.
>
> Maybe that's because most people see value in git that's unrelated to
> (supporting) decoupling.
>

I can appreciate that. I find lots of value in git for many of my
projects; however, that isn't the subject at hand. I'm truly interested
in how to structure git (work flow, repositories, what-not) to work for
a project like Boost.

Maybe there is a link to this already.

michael


--

----------------------------------
Michael Caisse
Object Modeling Designs
www.objectmodelingdesigns.com


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[greened]

Thomas Heller <[hidden email]> writes:

> On 02/08/2012 07:30 AM, Steven Samuel Cole wrote:

>> A quick read on submitting bugs on boost.org, svn co yadi yadi, fix the
>> typos locally. Of course I don't have write privileges to the repo, so
>> the best I can do for now is create a patch and attach that to a bug
>> report. Within minutes, someone takes care of the bug, comments and
>> takes ownership. Excellent! Smithers, money fight!
>
> Great! Now with something like github you create your own fork, push
> to that and eventually create a pull request and wait until it gets
> applied ... as you described. The process didn't change. You just
> named the steps differently.

No.  The fundamental part you're missing is that the source control
utility (git in this case) handles it for you.  There is no need to go
outside the sournce control utility to make additional changes.

>> What are my options now ? Revert my changes, base the new ones on the
>> head revision and send another patch ? Create a new patch file and
>> manually remove the diffs of the old changes I already sent ? How will
>> the upstream maintainer know which changes are based on what version ?
>
> Simple. Update the bug you already filed with the patch containing all
> fixes. What would be the options with git? Update the pull request?
> Again, same thing, different name.

No, not the same thing.  Again, this is all happening within the source
control utility.

Steven is relating real issues with svn.  I have encountered them many
times.  I have found that git eliminates them.

>> Also, I notice a few other things that in my opinion could be done
>> better to facilitate adoption of the iostreams library.

> So with git you pushed them to your personal fork. Over time, your
> fork and the upstream version eventually diverge. You have to maintain
> your changes. Same thing when the changes lurk on your local svn
> working.

There are several advantages to a git fork over an svn local workarea.

- You can make a new branch for each feature, keeping the code for
  logical features separate.  You can submit them whenever you want, in
  whatever order you want.

- You can share the forks and branches with others.

- You can massage the fork/branch over time to respond to review
  feedback, all supported directly by the source control utility.  IME,
  git rebase -i and git add -i are killer features for the code review
  process.

>> A couple of hours later: I get an email from boost bugs/svn; the
>> upstream maintainer has committed my changes. However, I actually
>> receive not one, but two emails, because the upstream guy chose to split
>> my patch into changes on documentation and changes on source code (which
>> presumably required extra work on his part).
>
> Frankly, I don't see how this would change with git.

Actually, git would make things easier for the maintainer here.  Either
he/she could request the submitter to break up the patch, which is
easily done with rebase -i/add -i or the maintainer could use the same
tools to do it him/herself.

>> I do an svn up and now have to deal with conflicts between my local
>> changes and the new commits: I make a note of my second set of changes
>> and overwrite my local files with the new repo versions, then bring the
>> second set back in.
>
> Same again. How is this significantly different to what you'd do with git?

It's all within the utility.  There's no need to back out patches (the
second set of changes in this case) manually from the source and
re-apply them manually after update.  Because each feature is in its own
(local) branch, updates of one branch don't conflict with unrelated
features in other branches.  Yes, you'll need to resolve conflicts but
it's much less messy with this kind of separation.

>> Uff! That's a lot of work just to fix some typos! And these are just
>> cosmetic issues in discrete chunks that do not require any testing;
>> contributing changes to source code would take even more effort and more
>> caution - build and test on several platforms, peer review, etc.
>
> Right, all that wouldn't change with having git as the tool of choice.

It does, dramatically.  git actually directly supports workflows that
developers use when working on large projects.  svn does not and there
are all sorts of hacks out there to work around those problems.  I've
written a fair number myself.  I don't need any of them with git.

>> I don't have to wait for the first set of changes to be merged into
>> the trunk before I resync, resolve conflicts and base the second
>> set on the new head revision; I simply create a new branch for
>> a new change set and send a new pull request once my work is complete.
>
> Errm ... you can still do that with svn. just continue working. Make a
> new patch, update the patch in the bug report you filed, yes trac can
> do that. There really is no need to wait for anything.

But now you're conflating multiple features.  Many times I have a
feature in-progress and another feature I'd like to work on that's
unrelated to the first feature.  I don't want to disturb the source tree
of the first feature because I might have to update it (respond to
feedback, etc.).  I need to be able to test both features in isolation.

>> The upstream maintainer has no peer pressure to merge any changes in:
>> He/she is sitting on the head revision and is looking at a number of
>> pull requests for change sets in various personal forks like mine;
>
> So, how is it really different from the current trac system?

svn doesn't support distributed operation so it can't support
cherry-picking from multiple developers.  You have to go outside the
tool (manual diff/patch) to do it.  That is painful.

> I think i miss something fundamental here.

Yes, you are.  You're missing that every operation Steven is talking
about is directly supported in git.  You use the source control tool to
manage source changes, always.  There's no need to ever do a manual
diff/patch.  git manages multiple changes for you and organizes them in
a logical way.  It is easy to change among them, apply some, test them,
revert some of them and so on.

It's incredibly easy and productive compared to doing the same in svn.

> While there are shortcomings in the current process, they won't be
> solved by changing tools.

Many will be.

                               -Dave

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[dag]

> The only downside (I can see) with GIT is that it has a bit of a learning curve.

It is a bit more complicated but I believe (and experienced myself) that
a lot of that learning curve is unnecessarily steep due to the way many
of the tutorials out there are written.  For some reason most of them
start out describing the guts and inner workings of git (blobs, trees,
packs, etc.) rather than teaching workflows.

The one great exception I've found to this is Scott Chacon's fabulous
_Pro_Git_ (http://progit.org/book).  It teaches you how to use git to
manage sources.  Reading that is what make it "click" for me.

                            -Dave

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Edward Diener-3]

On 2/8/2012 6:42 PM, David A. Greene wrote:

>
> Thomas Heller<[hidden email]>  writes:
>
>> On 02/08/2012 07:30 AM, Steven Samuel Cole wrote:
>
>
>> I think i miss something fundamental here.
>
> Yes, you are.  You're missing that every operation Steven is talking
> about is directly supported in git.  You use the source control tool to
> manage source changes, always.  There's no need to ever do a manual
> diff/patch.  git manages multiple changes for you and organizes them in
> a logical way.  It is easy to change among them, apply some, test them,
> revert some of them and so on.

Tell me how git magically manages to merge changes by multiple
developers to the same file when a local repository is pushed to another
one somewhere else. I alway hear this but refuse to believe it,
especially as changes made to the second repository are often occuring
before the developer pushing his changes is even aware of them.

I can not for the life of me see how this is different from multiple
developers merging their changes to a central repository in SVN. But Git
users always claim how much better this is, or must be, and I feel like
the little boy declaring that the emperor has no clothes.

Git users really have to stop claiming that Git is somehow better
because a distributed VCS system is magically better than a centralized
one when it comes to merging changes to the same source. Having good
merge tools has nothing to do with whether one uses a centralized or
distributed VCS, but rather whether a merge tool can allow the end-user
to decide if changes made to an already changed source can be done well
enough so as not break code and be logically coherent. Git may have
better tools for this than SVN but I can see no reason why this has to
do with a distributed VCS and a centralized VCS.

I have manually merged changes for years and I do not believe any merge
tool can be so foolproof to automatically merge changes and guarantee
that code will not be broken once someone else has made changes to
source between the time when I first picked up the latest copy and the
time when I seek to update my copy with my changes.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Steven Samuel Cole]

David A. Greene wrote:
 > guts and inner workings

i found http://help.github.com incredibly helpful to get going.
it seems to come from the opposite side, though - i had my github
account, the spoon-knife test repo and some project forks up and running
within minutes, as that's mostly just mouse clicks on a website - but i
still hadn't really grasped gits concepts.

next, i wanted to change some code in projects i had forked.
host:~ user$ git help
--> gives an overview of what commands are available, many of them are
familiar from svn or other VCSs
host:~ user$ git help <command>
--> explains <command> in detail

i got a few minor things wrong the first time i tried them and i still
have not seen everything git can do, but from my experience, most people
will be up and running in git after half a day at the most.

git is definitely easier to get your head around than some of the stuff
done in some of the boost libraries ;-)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Tim Blechmann-2]

> I am interested in your views here. I have had good success with git and
> monolithic projects. How would you go about working on your library and
> then pushing to the central repo. Would you envision that the central
> repo is nothing more than a shell pointing to submodules that are the
> "real" library repos?

the semantics of git submodules is a bit weird: if you check out a new
revision of the top-level repository, the submodules won't be updated
automatically, but you need to run `git submodules update' manually ... i am
using submodules for tracking some external dependencies and in my experience
70% of the compile failures of my users are related to submodules getting out
of sync.

for a project like boost, i'd therefore suggest to avoid submodules. the
advantage however is that the full git repository of boost is few hundred mb
...

> Or would you just rebase all of boost before
> committing back modifications to your library? Or some other process
> completely?

if changes are trivial, i usually rebase to the current master before pushing
new changes to the public repository. the reason is mainly to avoid
unnecessary merge commits in the history. if changes get too complex, merging
is usually better ... also more friendly for bisecting bugs.


> I'm sure people have thought about this problem and the solutions. You
> might be one of them. Unfortunately I mostly hear how great it would be
> to move to git but few have provided the usage for a project like boost
>
> : a loosely coupled and independently developed collection of libraries.

well, just because git provides some features, we do not necessarily have to
use them ... it can be used in a similar manner to the current svn repository,
only managing two branches

cheers, tim


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Tim Blechmann-2]

> > with svn your working copy gets easily out of sync ...
>
> svn update is all you need. ever. There are conflicts from time to time.
> Man up resolve them.

true, but in my experience resolving conflicts with svn is much more fragile
than with git ...

> > the nice thing of git is that it does not really harm if your branch
> > diverges from upstream, as its merge facilities are much more
> > sophisticated than everything that subversion has to offer ...
>
> I've heard that a couple of times now. My personal experience with git
> however is quite the contrary. I regularly mess up my local repository.

well, you need to have an understanding of what you are doing ... but at least
all you changes are stored inside the local repository. if you mess with your
local changes, you can revert to them, if you mess with a working copy, you
mess with files that you cannot got back to ...


> > frankly, since i moved my code into boost's svn, i find it way more
> > fragile to maintain than before
>
> Yes, I used to advertise git too. I had the exact same experience. That
> goes away. After a while, you won't look back to git, and enjoy "svn up"
> and "svn commit" and

svn was a relief for me after using cvs ... i've had the same feeling when
switching to git a few years later. using svn again (for boost), it really
feels like a bad joke ...


> start to question the usefulness of decentralized
> version control systems for a centralized boost altogether.

just because git is decentralized does not mean you cannot use it for
centralized projects.

tim

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Thomas Klimpel]

Tim Blechmann wrote:
> just because git is decentralized does not mean you cannot use it for
> centralized projects.

+1

Considering the challenge of changing the test infrastructure from the current parallel "trunk" and "release" repositories to anything else, it could make sense to move to git, but stays with the current organization and "discourage" public branches (or more precisely "pull requests" from public branches).

Regards,
Thomas

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost