You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Michael March <mm...@gmail.com> on 2006/06/08 21:18:41 UTC
Subversion 101: To lock or not to lock..
I am the new guy on a young project.. the project has 10 -> 15 Java
developers. The app is a JBoss app that implements the JBoss Portal
(kinda like a Java version of PHPNUKE).
The project is only a few months old and the project is constantly
changing.. very much in flux.
Here is the problem, I am the SCM on the project and I am telling
everyone based on my experience no one should be locking of any files
(text) on check out. Everyone else on the project is insisting that
some files should be locked on check out.
I showed everyone THE page in the official manual and they don't seem
to care. I shared my previous expereiences on other projects and that
didn't move them. Their line is this: In the new way of fast paced
Java web programming.. you are going to have a ton of conflicts and
merges all the time and it thus it doesn't lend itself to the
'non-locking' way of using Subversion.
Does anyone have any advice for what I should say or how to handle
this situation?
Or.. is their anyone out there using a locking model when working on a
Java web project?
thanks!
--
<admiral>
Michael F. March ----- mmarch_aaattt_gmail.com
"Seriously" - HSR
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 101: To lock or not to lock..
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
Duncan Murdoch wrote:
> On 6/8/2006 5:18 PM, Michael March wrote:
>> I am the new guy on a young project.. the project has 10 -> 15 Java
>> developers. The app is a JBoss app that implements the JBoss Portal
>> (kinda like a Java version of PHPNUKE).
>>
>> The project is only a few months old and the project is constantly
>> changing.. very much in flux.
>>
>> Here is the problem, I am the SCM on the project and I am telling
>> everyone based on my experience no one should be locking of any files
>> (text) on check out. Everyone else on the project is insisting that
>> some files should be locked on check out.
>>
>> I showed everyone THE page in the official manual and they don't seem
>> to care. I shared my previous expereiences on other projects and that
>> didn't move them. Their line is this: In the new way of fast paced
>> Java web programming.. you are going to have a ton of conflicts and
>> merges all the time and it thus it doesn't lend itself to the
>> 'non-locking' way of using Subversion.
>>
>> Does anyone have any advice for what I should say or how to handle
>> this situation?
>
> If conflicts from concurrent edits would be a problem, then conflicts
> of the "Arrgh! Joe still has that file locked!" variety will be a
> problem when using locking.
>
> Both are reduced by telling people to update and commit frequently.
>
> Duncan Murdoch
And slapping them in the head and teaching them to use their own branches.
Simultaneous code editing is always an adventure, and that's why you merge
them back to the trunk when they're ready to be committed.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 101: To lock or not to lock..
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 6/8/2006 5:18 PM, Michael March wrote:
> I am the new guy on a young project.. the project has 10 -> 15 Java
> developers. The app is a JBoss app that implements the JBoss Portal
> (kinda like a Java version of PHPNUKE).
>
> The project is only a few months old and the project is constantly
> changing.. very much in flux.
>
> Here is the problem, I am the SCM on the project and I am telling
> everyone based on my experience no one should be locking of any files
> (text) on check out. Everyone else on the project is insisting that
> some files should be locked on check out.
>
> I showed everyone THE page in the official manual and they don't seem
> to care. I shared my previous expereiences on other projects and that
> didn't move them. Their line is this: In the new way of fast paced
> Java web programming.. you are going to have a ton of conflicts and
> merges all the time and it thus it doesn't lend itself to the
> 'non-locking' way of using Subversion.
>
> Does anyone have any advice for what I should say or how to handle
> this situation?
If conflicts from concurrent edits would be a problem, then conflicts of
the "Arrgh! Joe still has that file locked!" variety will be a problem
when using locking.
Both are reduced by telling people to update and commit frequently.
Duncan Murdoch
>
> Or.. is their anyone out there using a locking model when working on a
> Java web project?
>
> thanks!
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 101: To lock or not to lock..
Posted by Adrian Howard <ad...@quietstars.com>.
On 8 Jun 2006, at 22:18, Michael March wrote:
[snip]
> I showed everyone THE page in the official manual and they don't seem
> to care. I shared my previous expereiences on other projects and that
> didn't move them. Their line is this: In the new way of fast paced
> Java web programming.. you are going to have a ton of conflicts and
> merges all the time and it thus it doesn't lend itself to the
> 'non-locking' way of using Subversion.
[snip]
In my experience the more often your committing/merging the less
sense locking makes. The quicker you find and identify conflicts the
easier they are to resolve. Hiding them behind locking and branches
causes more problems than it solves.
It sounds like your group might be locked into the "this is my code"
mindset rather than "this is our code" maybe?
You might want to read the rather spiffy (IMHO anyway) "Software
Configuration Management Patterns: Effective Teamwork, Practical
Integration" by Steve Berczuk with Brad Appleton. Lots of excellent
advice.
Hope this helps (and my sympathies :-)
Cheers,
Adrian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 101: To lock or not to lock..
Posted by Russ <rs...@istandfor.com>.
We use subversion with coldfusion, and haven't had any issues relating to conflicts that couldn't easily be solved through the diff tool in tourtoise or subclipse... Its perfectly fine for 2 people to modify the same html file and if they're not working on the same change, subversion will usually merge the changes quite gracefully.
Russ
Sent wirelessly via BlackBerry from T-Mobile.
-----Original Message-----
From: "Michael March" <mm...@gmail.com>
Date: Thu, 8 Jun 2006 16:23:30
To:users@subversion.tigris.org
Subject: Re: Subversion 101: To lock or not to lock..
Ok.. I printed out all the excellent comments from all of you and had
meeting with the 'pro-locking' factions here at the ranch.
A lot of the issues of why people want locking is because of a general
lack of training and knowledge of how and why Subversion works. As the
SCM this is my fault and its up to me to fix those issues.
However, of all the points the 'pro-lock' people made.. this one has
the most weight in my opinion. Here is a quote re:JSP and XHTML.. see
what you guys and gals think:
"When editing an html or jsp file, it is often necessary to modify
many parts of the file. If someone else is also editing the same
file, merging the changes can be extremely time consuming, as it is
hard for subversion to reconcile and display the diffs correctly (this
is from experience). Locking provides a safeguard from having to
endure the merge process but does not stop people from getting their
job done, because you should never have two people working on the same
html/jsp file at the same time."
On 6/8/06, Michael March <mm...@gmail.com> wrote:
> I am the new guy on a young project.. the project has 10 -> 15 Java
> developers. The app is a JBoss app that implements the JBoss Portal
> (kinda like a Java version of PHPNUKE).
>
> The project is only a few months old and the project is constantly
> changing.. very much in flux.
>
> Here is the problem, I am the SCM on the project and I am telling
> everyone based on my experience no one should be locking of any files
> (text) on check out. Everyone else on the project is insisting that
> some files should be locked on check out.
>
> I showed everyone THE page in the official manual and they don't seem
> to care. I shared my previous expereiences on other projects and that
> didn't move them. Their line is this: In the new way of fast paced
> Java web programming.. you are going to have a ton of conflicts and
> merges all the time and it thus it doesn't lend itself to the
> 'non-locking' way of using Subversion.
>
> Does anyone have any advice for what I should say or how to handle
> this situation?
>
> Or.. is their anyone out there using a locking model when working on a
> Java web project?
>
> thanks!
>
> --
> <admiral>
>
> Michael F. March ----- mmarch_aaattt_gmail.com
>
> "Seriously" - HSR
>
--
<admiral>
Michael F. March ----- mmarch@gmail.com
Ph: (415)462-1910 ---- Fax: (602)296-0400
P.O. Box 2254 ---- Phoenix, AZ 85002-2254
"Seriously" - HSR
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 101: To lock or not to lock..
Posted by "M. Rohrmoser" <mr...@gmx.de>.
Michael March wrote:
> "When editing an html or jsp file, it is often necessary to modify
> many parts of the file.
That's not jsp/html specific at all but IMHO holds for almost every kinda sourcecode.
What you tell sounds to me like you struggle to change the culture of a stubborn crowd. I'd say
chances aren't good to do so by education (tell'em about XP, agile processes, the "pragmatic" stuff
etc.) nor by brute force ("I'm in charge and just decide").
Best is to make small changes that return a visible benefit for ALL and feels comfortable. That's
what I experienced back when I introduced continuous integration. First no one bothered or was
negatively biased. But after a few weeks everybody enjoyed the immediate feedback after a commit -
everthing works!
So maybe don't set up a policy concerning locking at all, but ensure that who needs to edit in case
can break the lock - to avoid productivity blocks. And get'em to accept that everybody can edit
everything at any time. No private code ownership. Maybe things sort out by itself.
Greetings,
M
P.S.: Please tell us your experiences after several weeks.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 101: To lock or not to lock..
Posted by Andrew MacKenzie <am...@edespot.com>.
> Ok.. I printed out all the excellent comments from all of you and had
> meeting with the 'pro-locking' factions here at the ranch.
>
> A lot of the issues of why people want locking is because of a general
> lack of training and knowledge of how and why Subversion works. As the
> SCM this is my fault and its up to me to fix those issues.
Sounds to me like you're hitting a lot of 'developer inertia.'
We are in the midst of a similar switch from VSS to SVN and I'm hitting the
same pushback. Luckily here the developers are a bit more open to the idea
of letting SVN handle merging.
> "When editing an html or jsp file, it is often necessary to modify
> many parts of the file. If someone else is also editing the same
> file, merging the changes can be extremely time consuming, as it is
> hard for subversion to reconcile and display the diffs correctly (this
> is from experience). Locking provides a safeguard from having to
> endure the merge process but does not stop people from getting their
> job done, because you should never have two people working on the same
> html/jsp file at the same time."
XML/HTML/et al are a bit more of a special case actually. Especially if
it's machine generated. We've had some issues with .NET projects and
auto-generated XML files. The problem is that the XML elements aren't
necessarilly always re-generated in the same order, and thus the 'diff'
utility doesn't help very much - too much has moved.
But for hand-edited files this shouldn't be a problem, unless you have
people moving lots of tags for no apparent reason.
Personally, I'm a much bigger fan of a carful 'merge' than I am of waiting
for Fred to unlock a file so I can edit and test some changes...
The only thing we use locking for is binary files.
--
// Andrew MacKenzie | http://www.edespot.com
// GPG public key: http://www.edespot.com/~amackenz/public.key
// "Money is flat and was meant to be piled up."
// -- Scottish Proverb
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 101: To lock or not to lock..
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
----- Original Message -----
From: "Andy Levy" <an...@gmail.com>
To: "L. Wayne Johnson" <wa...@zk.com>
Cc: "Michael March" <mm...@gmail.com>; <us...@subversion.tigris.org>
Sent: Thursday, June 08, 2006 8:16 PM
Subject: Re: Subversion 101: To lock or not to lock..
> On 6/8/06, L. Wayne Johnson <wa...@zk.com> wrote:
>> >> "When editing an html or jsp file, it is often necessary to modify
>> >> many parts of the file. If someone else is also editing the same
>> >> file, merging the changes can be extremely time consuming, as it is
>> >> hard for subversion to reconcile and display the diffs correctly (this
>> >> is from experience). Locking provides a safeguard from having to
>> >> endure the merge process but does not stop people from getting their
>> >> job done, because you should never have two people working on the same
>> >> html/jsp file at the same time."
>> >>
>> This statement does not make sense to me. On the one hand merging the
>> file
>> is too time consuming so you must lock it.
>
> Locking most definitely can stop people from getting their job(s)
> done. On my last major ASP project (using VSS), we had a directory
> full of utility functions in include files - a couple dozen functions
> sprinkled across about 8 files. At least a couple times a week, I had
> to call over the wall to my partner "hey, are you using that file? If
> not, can you please unlock it? I'm stopped until I can fix this
> function."
This looks like the reason SVN 1.3.x introduced the "force unlock" options,
so that the second person can break the lock of the first person.
There is no graceful solution to two people working on the same file at the
same time. The real Subversion solution is to use branches, and merge
differences when each person is done, not to each lock the same copy.
> What's even worse is when you have to tell the project manager on
> Wednesday "I can't fix those 3 bugs this week because the guy on
> vacation till Monday has those files locked, and if we have the admin
> break the lock we'll have a hell of a time trying to get everything
> merged and synced up again."
>
>> On the other hand locking the file does not cause a problem because
>> nobody else will be working on it.
>
> In other words, why bother locking in the first place?
>
> This sounds more like the developers don't want change, or are trying
> to push the new SCM guy around.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 101: To lock or not to lock..
Posted by Andy Levy <an...@gmail.com>.
On 6/8/06, L. Wayne Johnson <wa...@zk.com> wrote:
> >> "When editing an html or jsp file, it is often necessary to modify
> >> many parts of the file. If someone else is also editing the same
> >> file, merging the changes can be extremely time consuming, as it is
> >> hard for subversion to reconcile and display the diffs correctly (this
> >> is from experience). Locking provides a safeguard from having to
> >> endure the merge process but does not stop people from getting their
> >> job done, because you should never have two people working on the same
> >> html/jsp file at the same time."
> >>
> This statement does not make sense to me. On the one hand merging the file
> is too time consuming so you must lock it.
Locking most definitely can stop people from getting their job(s)
done. On my last major ASP project (using VSS), we had a directory
full of utility functions in include files - a couple dozen functions
sprinkled across about 8 files. At least a couple times a week, I had
to call over the wall to my partner "hey, are you using that file? If
not, can you please unlock it? I'm stopped until I can fix this
function."
What's even worse is when you have to tell the project manager on
Wednesday "I can't fix those 3 bugs this week because the guy on
vacation till Monday has those files locked, and if we have the admin
break the lock we'll have a hell of a time trying to get everything
merged and synced up again."
> On the other hand locking the file does not cause a problem because nobody else will be working on it.
In other words, why bother locking in the first place?
This sounds more like the developers don't want change, or are trying
to push the new SCM guy around.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 101: To lock or not to lock..
Posted by Ulrich Eckhardt <ec...@satorlaser.com>.
On Friday 09 June 2006 01:43, L. Wayne Johnson wrote:
> >> "When editing an html or jsp file, it is often necessary to modify
> >> many parts of the file. If someone else is also editing the same
> >> file, merging the changes can be extremely time consuming, as it is
> >> hard for subversion to reconcile and display the diffs correctly (this
> >> is from experience). Locking provides a safeguard from having to
> >> endure the merge process but does not stop people from getting their
> >> job done, because you should never have two people working on the same
> >> html/jsp file at the same time."
>
> This statement does not make sense to me. On the one hand merging the file
> is too time consuming so you must lock it. On the other hand locking the
> file does not cause a problem because nobody else will be working on it.
>
> Either more than one person is going to edit the file or not.
A lock communicates that someone else is working on a file before(!) you start
working on it too (i.e. before you spend time/money/effort working on it).
This then gives you a chance to first coordinate changes with the other
person.
The alternative is that both change the file and the second one to commit
changes first has to merge the other changes. In cases where merging is more
time consuming than the communicate-before-edit approach above it is useful
to lock files. In particular when you can't automate merging (like with many
binary formats) this is the case.
Uli
****************************************************
Visit our website at <http://www.domino-printing.com/>
****************************************************
This Email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this Email in error please notify the system manager.
This footnote also confirms that this Email message has been swept by MailSweeper for the presence of computer viruses.
****************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Subversion 101: To lock or not to lock..
Posted by "L. Wayne Johnson" <wa...@zk.com>.
>> "When editing an html or jsp file, it is often necessary to modify
>> many parts of the file. If someone else is also editing the same
>> file, merging the changes can be extremely time consuming, as it is
>> hard for subversion to reconcile and display the diffs correctly (this
>> is from experience). Locking provides a safeguard from having to
>> endure the merge process but does not stop people from getting their
>> job done, because you should never have two people working on the same
>> html/jsp file at the same time."
>>
This statement does not make sense to me. On the one hand merging the file
is too time consuming so you must lock it. On the other hand locking the
file does not cause a problem because nobody else will be working on it.
Either more than one person is going to edit the file or not.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 101: To lock or not to lock..
Posted by Michael March <mm...@gmail.com>.
Ok.. I printed out all the excellent comments from all of you and had
meeting with the 'pro-locking' factions here at the ranch.
A lot of the issues of why people want locking is because of a general
lack of training and knowledge of how and why Subversion works. As the
SCM this is my fault and its up to me to fix those issues.
However, of all the points the 'pro-lock' people made.. this one has
the most weight in my opinion. Here is a quote re:JSP and XHTML.. see
what you guys and gals think:
"When editing an html or jsp file, it is often necessary to modify
many parts of the file. If someone else is also editing the same
file, merging the changes can be extremely time consuming, as it is
hard for subversion to reconcile and display the diffs correctly (this
is from experience). Locking provides a safeguard from having to
endure the merge process but does not stop people from getting their
job done, because you should never have two people working on the same
html/jsp file at the same time."
On 6/8/06, Michael March <mm...@gmail.com> wrote:
> I am the new guy on a young project.. the project has 10 -> 15 Java
> developers. The app is a JBoss app that implements the JBoss Portal
> (kinda like a Java version of PHPNUKE).
>
> The project is only a few months old and the project is constantly
> changing.. very much in flux.
>
> Here is the problem, I am the SCM on the project and I am telling
> everyone based on my experience no one should be locking of any files
> (text) on check out. Everyone else on the project is insisting that
> some files should be locked on check out.
>
> I showed everyone THE page in the official manual and they don't seem
> to care. I shared my previous expereiences on other projects and that
> didn't move them. Their line is this: In the new way of fast paced
> Java web programming.. you are going to have a ton of conflicts and
> merges all the time and it thus it doesn't lend itself to the
> 'non-locking' way of using Subversion.
>
> Does anyone have any advice for what I should say or how to handle
> this situation?
>
> Or.. is their anyone out there using a locking model when working on a
> Java web project?
>
> thanks!
>
> --
> <admiral>
>
> Michael F. March ----- mmarch_aaattt_gmail.com
>
> "Seriously" - HSR
>
--
<admiral>
Michael F. March ----- mmarch@gmail.com
Ph: (415)462-1910 ---- Fax: (602)296-0400
P.O. Box 2254 ---- Phoenix, AZ 85002-2254
"Seriously" - HSR
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org