Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Finding a patch's kernel version with git
Posted Jun 18, 2010 13:34 UTC (Fri) by farnz (guest, #17727)
No, I read it, but I thought you were completely and utterly out of touch with reality. Everyone I know who uses source control has multiple branches; if nothing else, you branch when you tag so that you have somewhere to work on maintenance fixes separately from your feature improvements. All that the difficulty in merging that SVN and CVS impose (but other centralised systems don't - this isn't a natural advantage of DVCSes) does is ensure that I'm more likely to make the sort of human error that I mention in my post.
Clearly, you did not bother to read my post; you just saw a counterexample to your point, and decided to play hurt.
Posted Jun 20, 2010 7:23 UTC (Sun) by chad.netzer (✭ supporter ✭, #4257)
Posted Jun 20, 2010 21:00 UTC (Sun) by marcH (subscriber, #57642)
Please demonstrate it in more detail, thanks. Warning: you're not allowed completely artificial commands or workflows that a regular SVN user would never use in pratice.
Posted Jun 21, 2010 8:11 UTC (Mon) by chad.netzer (✭ supporter ✭, #4257)
Any system of development with feature branches, release branches, and a trunk can allow this situation to occur, since not all features need be merged into trunk before a release. farnz's example was adequate; rev numbers themselves aren't an indicator of when and where a bug might have been merged into trunk. That's why nearly all modern systems have history visualization.
You were discussing "centralized systems", and made the claim "by making branching and merging expensive, you prevent yourself from going into a complicated situation where you cannot easily track commits any more." However, I was discussing SVN, and one of the features of SVN is that branches are cheap:
So, does your claim apply to SVN? If so, perhaps you can suggest a change to the example SVN workflow on Wikipedia, demonstrating "many branches", so that it can be improved.
Posted Jun 21, 2010 16:18 UTC (Mon) by marcH (subscriber, #57642)
This is about the implementation while I am talking about the workflow.
Please have a look at one of Linus' rants about centralized systems where he typically complains about the inconvenience of branching *and merging* in such systems.
Posted Jun 21, 2010 18:40 UTC (Mon) by chad.netzer (✭ supporter ✭, #4257)
If you mean that the common workflow in centralized systems does not allow long lived branches, and certainly not across releases, well I suppose I can accept that, but it is more a matter of discipline than central vs. distributed. Basically it means keeping non-mergeable feature branches out of the repository, or always rebasing them after a new release, so that branch rev ids are contained strictly between two releases. Neither option seems pleasant.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds