Re: How to best control non-working code with source control?

I think that you made a mistake by setting up your own CVS server. Version-control at a corporate level falls apart pretty-quickly when there are “sattelites.” I think that you needed to fork off your own branch, but that you needed to do so within the auspices of the version-control server (and system) that already existed in your organization.

Not-every branch “survives.” Not-every branch ought to. “Branches” do not have to be “functional.” If you spin-off a part of the development effort into a version-control system that is entirely disjoint from the one that the enterprise as a whole is using, I fear that you will completely negate all of version control's benefits....

Replies are listed 'Best First'.

Re^2: How to best control non-working code with source control?
by radiantmatrix (Parson) on Apr 15, 2008 at 18:02 UTC

I take your points about using branches, however:

If you spin-off a part of the development effort into a version-control system that is entirely disjoint from the one that the enterprise as a whole is using

That's not what I've done. Essentially, I have a "scratch" area where I can try things out, because the corp. policy says "no check-ins of non-working code". When I do fix a problem or add a feature, that immediately gets synced and checked into the corp. CVS -- so it isn't disjoint.

I essentially did with CVS what git seems designed to do (and better) -- created a local version history for code that isn't ready to share with others yet.

Based on your comment and others', it seems like the only real option I have is to try to get policy changed to allow me to create "unofficial" branches that contain non-working code, or to continue to do the bastardized process I have today.

<–radiant.matrix–>
Ramblings and references
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet

[reply]


Problems? Is your data what you think it is?
	PerlMonks