Re: Atomicity of locks and needs-lock

Duncan Booth wrote:
> Edward Harvey wrote:
>
>> If someone locked the file, they must be thinking that your changes,
>> whatever they are, won't be mergeable.
>>
> Rubbish.
>
> Say you are generating a release. You want to stop anyone else making
> checkins for a day or so while you are doing that, so locking all the files
> would seem a sensible move.

Interesting use of locks...

We usually cut a branch for that final release process and then a tag
when we get a release built and sent to QA. (Sometimes we just go
straight to the tag as the local WC is all that is used to do the build
and once it is done, a wc->tag copy is just the ticket)

> That doesn't stop anyone from making edits to some of the files in the
> expectation that you will unlock them again and then they can merge them.
> All it means is that you need some part of the repository to remain stable
> for a period while you run test suites, update documentation etc.

Like I said, that is usually what branches are for. Subversion makes
these so easy to deal with (and if an IDE has problems with new directories,
the "svn switch" of a local WC to the branch is an easy way to make the
IDE not get confused)

-- 
Michael Sinz                     Technology and Engineering Director/Consultant
"Starting Startups"                                mailto:michael.sinz@sinz.org
My place on the web                            http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org