[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: New Subversion Book Released

From: William Nagel <bill_at_stagelogic.com>
Date: 2005-05-28 18:51:23 CEST

Mi Moisei,

I do talk a lot about organizing branching, and how you can make that
an effective part of your development process. I think you may find
it helpful, even though I don't think I specifically address your use

One way to lock across branches would be to use a separate locking
directory, where developers could grab a lock on a copy of the file
when they wanted to work on any other copy of the file in a branch.
Then you could use a hook script to only allow the owner of that lock
to commit changes to the file on any branch. It would require you to
have very organized branches (or a unique naming scheme) in order for
the hook script to perform the matching, but it just might work for you.

Unfortunately, this doesn't solve the problem of ensuring that
developers don't waste time by working on a file they don't hold the
lock to. Off the top of my head, I'm not thinking of a good solution
to that problem across branches.


On May 28, 2005, at 4:27 AM, Moisei wrote:

> Hi,
> I setup the development process with subversion for the 30
> developers team.
> A big part of them are using MFC and I am just wondering about the
> management
> of the resource files (*.rc) generated automatically. How to
> prevent the case
> wheen 2 developers are working on the same dialog at the same time?
> I've waited for 1.2 locking to prevent such a cases at least in the
> trunk,
> but I do not find a good branching strategy.
> Is it covered in your book in some way?
> Or may be another resources,use-cases are known to somebody?
> Any help is very appreciated,
> Best Regards,
> Moisei.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat May 28 18:53:18 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.