Restricting users from creating branches...

RichardBrooksbyrb at geodesic.com RichardBrooksbyrb at geodesic.com
Wed Jun 24 10:17:48 PDT 1998


At 10:13 1998-06-24 -0700, David Jeske wrote:

> On Wed, Jun 24, 1998 at 11:04:21AM -0400, phardy at marketguide.com wrote:
> > That's something we can keep in mind. But for now, if someone wants to 
> > "experiment", they would already have a copy of the official code in
> > their client 
> > workspace. Within that workspace, they can do all the experimenting they 
> > want; but all code checked in must be already tested and approved.
>
> Dosn't that sort of defeat the purpose of source control? Before there was
> source control, people would hack and slash on code until it worked
> correctly, and then they would tar up a release, and save the source code,
> and that was their version control (or rather I should say that's how I
> did it). However, if you messed something up but had it working "a minute
> ago" then you had no way to get back to 'a minute ago'.
>
> The whole point of source control for me is to track every change I make. 
> I'm almost to the point where I just have the 'make' implicitly check in
> all my checked out files (but I don't do that yet). Then, when I get it
> working the way I wanted, I can give it a decent description and push it
> back to a useful part of the tree.

This could be an interesting debate.  What is the goal of source control?

I think the goal is to release higher quality software (i.e. better meeting
customer needs) by controlling the changes that are applied to that
software.  The idea is to make the right changes.  Changes not made to the
software don't matter.  The important thing is to control what affects the
source codeline that you release from.





More information about the perforce-user mailing list