Michael Pickard wrote:
>> -----Original Message-----
>> From: Andy Levy [mailto:email@example.com]
>> Sent: 24 July 2006 11:55
>> To: Michael Pickard
>> Cc: firstname.lastname@example.org; Nico Kadel-Garcia; Mike Craig
>> Subject: Re: Re: Suspending commits
>> On 7/24/06, Michael Pickard <email@example.com> wrote:
>>> Because there may be a need to rebuild if something fails UAT, hence
>>> 'without my prior authorisation'.
>>> If I needed to rebranch each time, I'd get at least one or two new
>>> branches a week *plus* any branches created by failed UAT - it
>>> would soon become unwieldy.
>> And your management is OK with development coming to a near-halt
>> every time UAT starts? Can't say I've worked in a place that would
>> accept that.
> I'm fine with it. The three developers concerned are perfectly able to
> work locally for a day.
>> You really ought to create tags and build from those. You'll get the
>> "lockdown" you're after (only allow one person to create tags), get a
>> "snapshot" of the code at any time as a result for repeatable builds,
>> and you don't have to stop developers from committing at all.
> OK, so let's say I create a tag and build for UAT from that.
> Dev A checks in some code,
> Dev B checks in some code,
> Dev A checks in some code,
> I'm notified of a failure in UAT and ask for a fix to be committed,
> Dev C checks in a fix
> I tag and build again.
> Isn't there a chance that the new build contains code submitted by A
> B that may break an area of the codebase not covered by UAT ?
Er, no. Don't create a new tag--just merge the specific change you
requested into your existing tag.
>> If that still seems "unweildy", why not make note of what revision
>> your initial UAT build came from, and if you need to rebuild, just
>> check out that specific revision instead of HEAD?
> For the same reasons as outlined above. A fix to code that has failed
> UAT might come after a number of other commits, none of which are
> scheduled for UAT, and for that reason I would like to restrict
> on the one day we do UAT.
This is definitely not a show-stopper. If you tag revision 400 and then
request a fix for a specific problem, and the fix is in revision 415,
you can just grab that specific revision in a merge--"svn merge -r
414:415 ." updates your local copy (the tag) with the change from
revision 414 to 415, but nothing else--thus, you'll only get the change
you requested. And, of course, you can release from the tag a lot
easier than releasing from a specific revision.
* NB: Some people feel that anything labelled a "tag" should not be
mutable, and thus have probably fainted at my suggestion of merging
changes into an existing tag. If you're one of those, then replace
every mention of "tag" to "branch" in my message, and consider tagging
from the branch once you pass UAT.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Jul 24 14:29:57 2006