You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Rick Mann <rm...@latencyzero.com> on 2005/06/07 23:22:27 UTC
Read-only checkouts/updates
I read the thread on read-only checkouts, and it seems to have
wandered from what the original poster asked for. I am in the same
boat as the original poster:
http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=28715
> Is there a method for obtaining a module that creates a read-only copy
> of the module? This way, if a developer wants to edit the file,
> they can
> then specifically checkout the file for editing. This will prevent
> accidental editing of files that a developer may not need to edit.
> Thanks,
I need for my working copy to be read-only. I don't want to lock
files for exclusive checkout, and I'm happy to use other tools to
make the file writable when I choose to edit it (my IDE asks me if I
want to make a file writable as soon as I try to type in it).
It's too easy to unwittingly modify a file otherwise. And because SVN
doesn't support partial checkins, it's a HUGE pain to determine that
a file should not be checked in.
This feature can be entirely client-side, and turned off by default,
but even crummy CVS allows this functionality.
Is this being considered for short-term implementation, and if not,
why not? If it's a reasonable request, should I add an Issue for it?
TIA
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Read-only checkouts/updates
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jun 8, 2005, at 11:55 AM, Ron Gilbert wrote:
>
> I have a very similar problem. I have a lot of non-technical
> people that need read-only access to the files, and, yes, they
> modify them all the time when they shouldn't be. Having them come
> down as read-only would solve about 99% of that problem.
I'm trying to understand the use-case here, because it seems new and
strange to me.
You guys are telling me that:
* you have a bunch of non-technical users
* they all need private working copies of the data
* they all need commit privileges
* they accidentally change lots of files, and then don't know which
ones to commit
?
How do files get accidentally changed?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Read-only checkouts/updates
Posted by Ron Gilbert <li...@rzweb.com>.
Ben Collins-Sussman wrote:
> On Jun 7, 2005, at 4:22 PM, Rick Mann wrote:
>>
>> Is this being considered for short-term implementation, and if not,
>> why not? If it's a reasonable request, should I add an Issue for it?
>
> It's not being considered for short-term implementation, because it's
> just not our UI model. Subversion, like CVS, is a concurrent system
> based on copy-modify-merge. The UI you're describing sounds
> something very much like SourceSafe or PerForce, where everything is
> read-only by default, and you have to 'declare' intent to edit
> somehow. That UI contradicts the design philosophy of Subversion.
>
> Do you really have problems "accidentally" modifying files? I've not
> heard of such a thing before.
I have a very similar problem. I have a lot of non-technical people that need read-only access to the files, and, yes, they modify them all the time when they shouldn't be. Having them come down as read-only would solve about 99% of that problem.
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Read-only checkouts/updates
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jun 7, 2005, at 4:22 PM, Rick Mann wrote:
>
> Is this being considered for short-term implementation, and if not,
> why not? If it's a reasonable request, should I add an Issue for it?
It's not being considered for short-term implementation, because it's
just not our UI model. Subversion, like CVS, is a concurrent system
based on copy-modify-merge. The UI you're describing sounds
something very much like SourceSafe or PerForce, where everything is
read-only by default, and you have to 'declare' intent to edit
somehow. That UI contradicts the design philosophy of Subversion.
Do you really have problems "accidentally" modifying files? I've not
heard of such a thing before.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org