Avoiding unexpected Concurrent Development

["Alejandro Lopez Rama(correos)" <al...@gmail.com>]

We're testing subversion for our version control development. One thing I've
seen is Subversion informs that you have a collission in one version with
another version developed by other people.
I suppose this is because in Subversion you always have the whole directory
checked out, instead the only source you want to modify. Is there a way to
check out the only sources I want to use, and when I want to check them out,
know if someone else has checked it out before?

Re: Avoiding unexpected Concurrent Development

[John Peacock <jo...@havurah-software.org>]

Alejandro Lopez Rama(correos) wrote:
> Is there a way to check out the only sources I want to use, and when
> I want to check them out, know if someone else has checked it out
> before?

No, Subversion only operates on directories, not individual files.  You 
should probably read the discussion here:

http://svnbook.red-bean.com/en/1.4/svn.basic.vsn-models.html#svn.basic.vsn-models.lock-unlock

for the philosophy behind Subversion's design, which is (like CVS) 
biased towards concurrent development.  However, in the spirit of 
TMTOWTDI*, you can also read this section:

http://svnbook.red-bean.com/en/1.4/svn.advanced.locking.html

for how you can limit concurrent development on specific files.  In fact 
you should probably read the entire book, if you want to do a complete 
evaluation.

John

* TMTOWTDI = There's More Than One Way To Do It

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: RE: Avoiding unexpected Concurrent Development

["Gleason, Todd" <tg...@impac.com>]

"resolves any merges upon checkin" is inaccurate and might scare people.
Here's my understanding of how it actually works:

 

Svn checkout = initial get

Svn update = subsequent get, merging changes into your working copy.
Conflicts (edits to the same areas of a text file) are resolved
interactively.

Svn commit = check-in-and if you try to commit a file that was committed
since your checkout or last update, your commit fails, forcing you to
update and merge.  You don't actually resolve merges when committing
(which is very dangerous to do!), you resolve them when updating.

 

________________________________

From: Reedick, Andrew [mailto:jr9445@ATT.COM] 
Sent: Thursday, April 03, 2008 8:12 AM
To: users@subversion.tigris.org
Subject: RE: Avoiding unexpected Concurrent Development

 

...

 

You don't checkout from Subversion.  Instead, a subversion checkout is
more like a 'get'.  Everyone 'gets' a copy of the files, works on them,
and then resolves any merges upon checkin.

 

 

*****

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other
use of, or taking of any action in reliance upon this information by
persons or entities other than the intended recipient is prohibited. If
you received this in error, please contact the sender and delete the
material from all computers. GA621

RE: Avoiding unexpected Concurrent Development

["Reedick, Andrew" <jr...@ATT.COM>]

Subversion is based on the copy-modify-merge paradigm, so it always
expects/assumes concurrent development.

http://svnbook.red-bean.com/en/1.4/svn.basic.vsn-models.html#svn.basic.v
sn-models.copy-merge

http://svnbook.red-bean.com/en/1.4/svn.basic.vsn-models.html#svn.basic.v
sn-models.lock-unlock

 

If you really want to follow a lock-modify-unlock paradigm, use 'svn
lock' and put svn:needs-lock on every file.  Obviously binary and other
unmergeable files should require a lock to work on.   

http://svnbook.red-bean.com/en/1.4/svn.advanced.locking.html

Generally speaking, using the lock-modify-unlock model for text files is
considered pretty silly.  If someone needs to work on a file, they need
to work on a file.  Requiring them to wait on someone else is
inefficient, especially since merge tools have gotten better.

 

Long story short, you should get used to the idea of merging when using
Subversion (or any version control tool for that matter.)  There's just
no way to avoid it w/o restricting everyone to serial development.  Even
with serial development I've seen people overwrite another person's
checkin just because they were too impatient to wait to get a file lock
and then were too lazy/afraid to merge.

 

 

There's no way to tell if someone else is working on a file unless the
'svn:needs-lock' is on the file.

 

You can tell if someone has checked in a change to a file that you're
working on by using 'svn status -u'.  However, that won't tell you if
someone else is actively working on the file but hasn't checked in their
changes yet.

 

You don't checkout from Subversion.  Instead, a subversion checkout is
more like a 'get'.  Everyone 'gets' a copy of the files, works on them,
and then resolves any merges upon checkin.

 

 

 

From: Alejandro Lopez Rama(correos) [mailto:alrlistas@gmail.com] 
Sent: Thursday, April 03, 2008 9:51 AM
To: users@subversion.tigris.org
Subject: Avoiding unexpected Concurrent Development

 

We're testing subversion for our version control development. One thing
I've seen is Subversion informs that you have a collission in one
version with another version developed by other people.

I suppose this is because in Subversion you always have the whole
directory checked out, instead the only source you want to modify. Is
there a way to check out the only sources I want to use, and when I want
to check them out, know if someone else has checked it out before?


*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621

RE: Avoiding unexpected Concurrent Development

[ni...@planet.nl]

Take a look at svn locking, check out only means "creating a local working copy" and has nothing to do with locking or preventing concurrent editing.

Hth,

Nick S.


-----Original Message-----
From: Alejandro Lopez Rama(correos) [mailto:alrlistas@gmail.com]
Sent: Thu 4/3/2008 15:50
To: users@subversion.tigris.org
Subject:  Avoiding unexpected Concurrent Development
 
We're testing subversion for our version control development. One thing I've
seen is Subversion informs that you have a collission in one version with
another version developed by other people.
I suppose this is because in Subversion you always have the whole directory
checked out, instead the only source you want to modify. Is there a way to
check out the only sources I want to use, and when I want to check them out,
know if someone else has checked it out before?