Re: [boost] [git] neglected aspects
Thomas Heller <thom.heller@googlemail.com> 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
On 2/8/2012 6:42 PM, David A. Greene wrote:
Thomas Heller<thom.heller@googlemail.com> 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.
Edward Diener wrote:
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 feel like the little boy declaring that the emperor has no clothes. No need - a certain amount of scepticism and critically questioning a
of course git does not magically solve that. i think the difference between svn and git to some extent is a different mentality: while both technically do support branching and merging, the process is much more heavyweight in svn than in git: an svn branch is often considered to last for weeks or months or even permanently - and once the big new feature it was created for has reached release maturity, merging the changes back in is a rather massive job. releases have failed because of this - code builds fine in dev branches, but once it's all merged, nothing compiles. this integration problem is one of the reasons why the whole continuous integration concept has come up in the last decade, see http://en.wikipedia.org/wiki/Continuous_integration. git circumvents this problem to some extent by anticipating the need for branches and merges as a central concept and incorporating it on a much lower level than svn; branches are much more lightweight and are possibly created and merged back in several times a day. Edward Diener wrote: proposed change is necessary to verify a concept is sound. I was not really convinced of git's benefits until I actually gave it a good test run on a small open source project on github. Takes only a couple of minutes. I also found I had to let go of my conventional understanding of source control systems: In contrast to a central svn server where one single head revision is pushed forward by changes from the team, git feels to me more like sets of changes are passed around between local repos - and one of them - one that gets special TLC - is the master branch. Does that makes sense ? # ssc
On Thu, Feb 9, 2012 at 11:54 PM, Steven Samuel Cole <steven.samuel.cole@gmail.com> wrote: > Edward Diener wrote: > releases have failed because of this - code builds fine in dev branches, but > once it's all merged, nothing compiles. this integration problem is one of > the reasons why the whole continuous integration concept has come up in the > last decade, see http://en.wikipedia.org/wiki/Continuous_integration. This link doesn't help your case at all: " Extreme Programming advocate Martin Fowler also mentions that where branching is supported by tools, its use should be minimized.[4] Instead, it is preferred that changes are integrated rather than creating multiple versions of the software that are maintained simultaneously. " If you don't branch a lot, you probably don't need git. (My personal experience strongly supports this, by the way. My former company used continuous integration this way with great success, though, they were projects very different from boost in its nature). > git circumvents this problem to some extent by anticipating the need for > branches and merges as a central concept and incorporating it on a much > lower level than svn; branches are much more lightweight and are possibly > created and merged back in several times a day. Branches _are_ lightweight in SVN (constant time). On the other hand, it is true, that their _usage_ is probably heavier weight than in git. Now, I don't see the use for so many branches. I see an overhead in using them though, because however efficient the tools may be you still need to think about your branching and perform some (however simple) manual operation. I would quote Python guys: it's easier to ask forgiveness than permission. I work on my trunk at all time, if for some reason I make a mistake, it's not too hard to cancel it. >> Steven Samuel Cole wrote: > I also found I had to let go of my conventional understanding of source > control systems: In contrast to a central svn server where one single > head revision is pushed forward by changes from the team, git feels to > me more like sets of changes are passed around between local repos > - and one of them - one that gets special TLC - is the master branch. > Does that makes sense ? I think that this (and local commits that SVN may get in the form of checkpoints in 1.8) is the one good reason to consider switching to git. Though changing the philosophy of working of many people is a huge roadblock. Boost has been committed to quality and wishes to make frequent releases leaving not much room for such a switch. To see whether this is good or not, well I guess you have to be an active boost developer (which I am not) and know patches actually flow around (andI don't). Julien
participants (4)
-
David A. Greene -
Edward Diener -
Julien Nitard -
Steven Samuel Cole