| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Subversion considers its future
Subversion considers its future
Posted May 1, 2008 14:33 UTC (Thu) by nix (subscriber, #2304)In reply to: Subversion considers its future by ras
Parent article: Subversion considers its future
I find it odd that you say that a VCS is of no benefit to a corporate coder. Do these paragons never make mistakes? Do they never have to support older code live at customer sites?
(Log in to post comments)
Subversion considers its future
Posted May 1, 2008 21:27 UTC (Thu) by dmag (subscriber, #17775) [Link]
> I find it odd that you say that a VCS is of no benefit to a corporate coder. I agree with the intent of the original poster, except maybe the wording was a bit strong. How's this: "Most corporate programmers don't get anything from VCS that they couldn't get from a tarball snapshot, while their employers could find the VCS data more useful." SVN makes branching and merging difficult, so the typical corporate programmer won't bother with it. > Do these paragons never make mistakes? Yes, but most of the time people just "fix the bug and move forward" rather than trying to go back to the old version. (I work a lot in web databases, and sometimes V2 requires altering fields in the DB. Going back to V1 usually means loosing the extra data.) > Do they never have to support older code live at customer sites? No, most corporate development is for internal deployments -- there's usually just one instance of their code running. Remember, only about 5% of programmers actually write code to sell.
That's incorrect
Posted May 1, 2008 22:27 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]
I play in both the corporate development world and the free software world, and anyone who thinks that corporate software development could be possible without a VCS is sorely mistaken. On the contrary, a VCS is vital.What is a debatable issue is whether a distributed revision control system is useful for the typical corporate software development process. In the typical corporate development flow, the centralized database is a key feature, used to enforce policies, and often tightly coupled to bug tracking, performance reviews, the works. Distributed repositories could help individual developers experiment with changes on a local basis, but management isn't going to like it because they can hide information from management (which might be a good thing if you sit on the other side of the divide).
That's incorrect
Posted May 5, 2008 3:23 UTC (Mon) by rganesan (subscriber, #1182) [Link]
> I play in both the corporate development world and the free software > world, and anyone who thinks that corporate software development could be > possible without a VCS is sorely mistaken. On the contrary, a VCS is > vital. I am in total agreement. I also play both in corporate development as well as free software world. Anyone who claims corporate development can work without VCS has never worked in one. With projects having upwards of 400 developers actively committing every day, do you guys seriously believe corporates can manage with a tar ball? I don't know if a distributed VCS would be very useful in a corporate setup. One of the biggest advantages of a distributed VCS (as I understand it) is to allow experimentation with a private branch. In a centralized VCS, a private branch gets created for this but it still stays centralized. "Distributed" in corporate development usually means a centralized but multi-site VCS.
That's incorrect
Posted May 5, 2008 11:51 UTC (Mon) by nix (subscriber, #2304) [Link]
Sure they can manage with a tarball. Everyone shares one huge build tree with all the source code and generated binaries in it: it gets `make clean'ed and tarred every night. (Not only have I worked at places that did this, *not even the tarring job was automated*. People can put up with a lot if they have no idea anything better is possible.)