Molle Bestefich wrote:
> Maik Schmidt wrote:
>> My superiors demands that the version management we will be using has
>> the possibility to tell the user that a file is in use by someone
>> other.
>
> They've got it all wrong. Subversion does automatic merges, so
> there's nothing wrong with two people working on the same file at the
> same time. Try it ;-p.
Sadly things aren't quite that black-and-white. If you use Subversion to
store binary files, such as word processor documents, then they can't be
merged.
In this case it sounds like the requirement isn't actually for locking,
just for knowing which files are being worked on. It may be that a better
scheme to handle this situation would simply be to ensure that all
development is done on branches (remember branches are cheap to create),
and checkins are done very frequently.
So before developer A starts working on issue #666 they create a
branch/issue-A-666 and make sure they do a checkin every time the unit
tests pass (e.g. every 10 minutes). Nobody else works on the same branch,
so you can see which files are being worked on by just looking at the
branch. When the developer has completed their work you then merge back to
the trunk. For this to work you may have to reeducate developers (I've
known some people not check work in for weeks at a time), but it lets you
track where the work is happening without impacting on separate
developments.
Another option might be for them to handle the issue entirely outside
Subversion: set up a background process to periodically run 'svn status'
over all of a developer's working copies and post the output files to a web
server which can process them and produce a report (or if the project
involves a makefile simply get the build step to do the 'svn status').
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Mar 23 11:48:44 2005