Perhaps you shouldn't rush to characterizing people as impolite...
The practical reason for the locks is that for files that cannot be
merged it can help avoid wasted work...
A person who is about to work on a file that cannot be merged (eg binary
file of some sort such as may art file formats), can exclusively lock it
before working on it. When this is part of the workflow, it means that
people won't waste time working on a file only one of them will be able
to commit.
Yes, one could argue that there are layers on top of version control
that should probably be tracking this dependency so that two people
don't end up working on tasks involving the same un-mergeable file at
the same time; how many shops have that level of detail task+asset
management detail [and let's include cost, eg leave AlienBrain out of
the discussion]?
The point is that this "feature" does serve a valid purpose, and the
version control layer can act as a very good self-defense mechanism. The
person who does it right and checks out exclusively before working is
the person who justifiably can check in their work.
At the very least I don't see the negative characterization you seem to
want to put on people holding views/workflow issues different than your
own.
As far as I know, subversion wasn't meant to satisfy the palate of only
one type of user/data.
Peter
-----Original Message-----
From: Kevin Williams [mailto:kevin@bantamtech.com]
Sent: Tuesday, November 16, 2004 11:54 AM
Cc: Subversion Users
Subject: Re: Checkout every file as read-only; make some of them
editable with a explicit command.
Exclusive checkouts vs. merge behavior is one of those never ending
discussions, like spaces vs. tabs, that is up to personal
interpretation. I believe the Subversion authors don't like exclusive
checkouts. Therefore, I believe this feature is only being added due to
popular demand. They are in no hurry because there's also a number of
people who don't need it.
Until Subversion offers both ways of doing things, it may help anyone
wishing for exclusive checkouts to try things "the Subversion way".
Create a test repository, have a few users use it, purposefully create
some conflicts, and follow the documentation to resolve the conflict. If
a majority finds they can work faster (assuming conflicts are rare if
project work is divided among developers) than if they run into
exclusive checkout restrictions, then the problem is solved.
It's a matter of personal taste. IMHO, it's like trying a food you've
never had - it's impolite to not at least TRY it before deciding it's
bad.
Hope that helps,
Kevin
Petri Varsa wrote:
> Version 1.2 is supposed to have this feature. I don't know when 1.2
> is supposed to be released, but the subversion roadmap mentions this
> feature.
>
> http://subversion.tigris.org/roadmap.html
>
> -petri
>
> -----Original Message-----
> From: Esteban Bolanos [mailto:ebolanos@datatec-ec.com]
> Sent: November 16, 2004 10:53 AM
> To: Subversion Users
> Subject: Checkout every file as read-only; make some of them editable
> with a explicit command.
>
> Hello,
>
> Is there a way to checkout files in read-only mode ("protected"
> files), and
> then enable the edition on just the files that one wants to work with?
>
> Some CVS users who are considering migrating to SVN asked me
this,
> because that's a "feature" that they use frequently. I don't know much
> about CVS, but they tell me that, with it, it's possible to checkout
> files in protected mode and then issue a "cvs edit" command only on
> the files they intend to change, in order to prevent accidental
> changes. All that I know about "cvs edit" is that it is normally used
> in the context of watches; howewer, they don't use it for change
> notification, but rather just as a protection mechanism.
>
> How could one achieve a similiar effect in SVN?
>
> Thanks,
> Esteban.
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.795 / Virus Database: 539 - Release Date: 12/11/2004
>
>
> ---------------------------------------------------------------------
> 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
>
---------------------------------------------------------------------
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
Received on Tue Nov 16 21:41:09 2004