Not logged in
Log in now
Create an account
Subscribe to LWN
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
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?
Subversion considers its future
Posted May 1, 2008 21:27 UTC (Thu) by dmag (subscriber, #17775)
> I find it odd that you say that a VCS is of no benefit to a corporate
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
> 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
Posted May 1, 2008 22:27 UTC (Thu) by JoeBuck (subscriber, #2330)
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).
Posted May 5, 2008 3:23 UTC (Mon) by rganesan (subscriber, #1182)
> 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
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
Posted May 5, 2008 11:51 UTC (Mon) by nix (subscriber, #2304)
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.)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds