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

RE: Concurrent versioning = spawn of the devil?

From: Thomas Hemmer <themmer_at_go-engineering.de>
Date: 2006-11-08 13:43:33 CET


let me spend my 2 cents on that issue ...

> He simply says that concurrent versioning is too dangerous,
> merging is too difficult and too much subject to error. He
> says that we are exposing our clients to too much risk if we
> subject their code to that kind of an environment.
Maybe he isn't such wrong with his opinion.
On the other hand, there are thousands of developer teams around the
globe who _practise_ merging in their everyday business (I've even been
told by one of those folks that they are _forced_ to do so because of
several reasons) ;-)
Should they all produce weak code???
By the way, I personally prefer the locking method since I am working
with a rather small team (5 dev's) sitting within the same building and
our projects are fairly small, too (a few dozens of source files which
together weigh maybe some 10000 LOC typically).
I have no experience in working on widely distributed projects with
dozens of dev's, but I very much suppose the locking approach might
simply not be applicable in such a scenario.

> It's not helping that we can't see when a file is locked
> until we try to check it in. I know ... the answer is "don't ...
Simply tell him to categorically update his working copy and lock the
file he is going to alter _before_ making any changes to his WC.
Either there already _is_ a lock set on that very file (or set of
files); then he is told so (svn even provides him with the reason why
the file is locked!) and should delay his work until the lock has been
released again.
Or there has'nt been any; in this case he can immediately start his work
while being sure noone else won't interfere with his efforts.

> Are there any other GUIs besided SmartSVN and Tortoise? I wasn't able
to find any...
You don't need to ;-)
IMHO it would be really hard to design a tool that outbeats TSVN ...

Hope this helps,


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 8 13:45:31 2006

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