A common practice in this situation is to have the trunk (or mainline)
the "well-known good" build. Developers branch off the trunk, make
changes, and test, then merge back into the mainline only when all tests
have passed. Of course, this is just a convention.
--Tim
Brass Tilde wrote:
>In our environment, we have numerous developers, all of whom are pretty much
>the sole responsible party for one or more applications for which we have
>ongoing development. It's seldom that we have two developers working on the
>same project.
>
>One of the ways that we're tossing around to make it easier for our build
>person to build our applications, before we get an automated build tool and
>implement it, is to have so-called "floating" tags in the repository.
>Basically, these would point to the latest safely buildable revision of the
>application in question. As far as I can tell, this would require deleting
>the existing contents of the directory in the repository that corresponds to
>our "Dev" tag every time we wanted to "float" the tag, correct?
>
>Our other option is to simply decree that the HEAD revision of each
>project's /trunk be the safely buildable version, and have all development
>handled either on a branch, which is merged to the trunk when stable, or in
>the WC with only stable stuff being checked in.
>
>Thoughts? Other ideas (that don't require we implement Ant, CruiseControl
>or something right away, but assuming that we *will* be implementing
>something along those lines at some point)?
>
>"Creationists make it sound as though a 'theory' is something you dreamt
>up after being drunk all night." -Isaac Asimov
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 2 22:04:41 2005