You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Patrick Hanna <pa...@openwave.com> on 2005/04/01 19:03:56 UTC
read-only checkouts
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,
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: read-only checkouts
Posted by Josh Pieper <jj...@pobox.com>.
Scott Palmer wrote:
> On Apr 2, 2005, at 12:54 PM, Josh Pieper wrote:
>
> >I think one of the advantages of this declared edit feature is that it
> >allows status/diff gathering to be blazingly fast. 'svn status' can
> >take absurdly long periods of time on large working copies. If there
> >were an option to have read-only checkouts and have a 'svn edit'
> >command make them read+write, Subversion could keep track of which
> >files had been edited and significantly speed up status, diff, commit,
> >etc. It would make svn usable on projects where working on only
> >portions of a large tree is not practical.
>
> Replace "svn edit" with "svn lock" and don't you have the same basic
> feature (minus the potential speedup for the status command) ???
No, the point is that you do not want an exclusive lock. You just
want to give svn some inside information on which files you are
editing. It is not uncommon for 'svn status' to take tens of minutes
to run on large working copies, even if you have only changed one or
two files. If the client side tools kept track of which files you had
told it you were editing, all of those checks (status/diff/commit)
would no longer depend upon the size of the working copy, just on the
size of the changes you had made.
-Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: read-only checkouts
Posted by Ben Collins-Sussman <su...@collab.net>.
On Apr 2, 2005, at 6:27 PM, Scott Palmer wrote:
>
> Ah. Any plans for "shared" or "non-exclusive" locks then? Basically
> informing the user that someone else is editing the file at the same
> time.
>
>
No plans yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: read-only checkouts
Posted by Scott Palmer <sc...@2connected.org>.
On Apr 2, 2005, at 5:25 PM, Ben Collins-Sussman wrote:
> On Apr 2, 2005, at 3:59 PM, Scott Palmer wrote:
>
>> On Apr 2, 2005, at 12:54 PM, Josh Pieper wrote:
>>
>>> I think one of the advantages of this declared edit feature is that
>>> it
>>> allows status/diff gathering to be blazingly fast. 'svn status' can
>>> take absurdly long periods of time on large working copies. If there
>>> were an option to have read-only checkouts and have a 'svn edit'
>>> command make them read+write, Subversion could keep track of which
>>> files had been edited and significantly speed up status, diff,
>>> commit,
>>> etc. It would make svn usable on projects where working on only
>>> portions of a large tree is not practical.
>>
>> Replace "svn edit" with "svn lock" and don't you have the same basic
>> feature (minus the potential speedup for the status command) ???
>
> No, because 'svn lock' prevents others from committing. The original
> poster said he doesn't want to disable concurrency, he just wants
> people to have to declare their intent to edit.
Ah. Any plans for "shared" or "non-exclusive" locks then? Basically
informing the user that someone else is editing the file at the same
time.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: read-only checkouts
Posted by "Kevin T. Broderick" <kb...@boltonvalley.com>.
On Apr 2, 2005, at 5:33 PM, Patrick Burleson wrote:
> On Apr 2, 2005 5:25 PM, Ben Collins-Sussman <su...@collab.net> wrote:
>>
>> No, because 'svn lock' prevents others from committing. The original
>> poster said he doesn't want to disable concurrency, he just wants
>> people to have to declare their intent to edit.
>
> I could see this being a fairly useful feature in some development
> environments. And it could all be done client side. Maybe something in
> the config file to turn on default "read-only" checkouts. Then a
> simple "edit" command to make them read only. (Not trying to imply
> that it would be a simple thing to implement, just a simple command)
As far as use cases go, I can think of one where this might be useful
(particularly in conjunction with the large-WC time issue for svn
status)--some development environments and editors have a nasty habit
of changing files silently, often for no apparent reason (e.g. a
machine-generated file, generated by the same program, will move around
two lines without changing either line's content). Or one might have a
large number of files open in an IDE to review calling structures, etc
and accidentally type a single character or a small number of
characters into the wrong window, followed by hitting "Save All" before
exiting. Both of these scenarios can be dealt with via svn status and
then dealing manually with the files that have cosmetic-only changes;
however, it may be helpful in some situations to be able to do an "$
svn checkout -noedit .... " that would provide read-only files
(leveraging the OS's ability to mark them that way) and then mark, in
the WC, that svn can assume all directories so marked have not changed
since checkout. Doing an " $ svn edit /filename/" would then cause
that file and the appropriate directory tree up to that file (from the
root of the WC) to be marked as possibly-changed, which could be
toggled with " $ svn edit ... " and " $ svn noedit ... ".
(my two cents. But on a slightly different note, many thanks to the
dev team for the functionality that is available...having an
inexpensive and generally easy-to-install versioning system available
makes my life a lot easier.)
Kevin Broderick, Bolton Valley IT Department
kbroderick@boltonvalley.com / 802.434.6807 (V) / 802.329.6807 (F)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: read-only checkouts
Posted by Patrick Burleson <pb...@gmail.com>.
On Apr 2, 2005 5:25 PM, Ben Collins-Sussman <su...@collab.net> wrote:
>
> No, because 'svn lock' prevents others from committing. The original
> poster said he doesn't want to disable concurrency, he just wants
> people to have to declare their intent to edit.
I could see this being a fairly useful feature in some development
environments. And it could all be done client side. Maybe something in
the config file to turn on default "read-only" checkouts. Then a
simple "edit" command to make them read only. (Not trying to imply
that it would be a simple thing to implement, just a simple command)
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: read-only checkouts
Posted by Ben Collins-Sussman <su...@collab.net>.
On Apr 2, 2005, at 3:59 PM, Scott Palmer wrote:
>
> On Apr 2, 2005, at 12:54 PM, Josh Pieper wrote:
>
>> I think one of the advantages of this declared edit feature is that it
>> allows status/diff gathering to be blazingly fast. 'svn status' can
>> take absurdly long periods of time on large working copies. If there
>> were an option to have read-only checkouts and have a 'svn edit'
>> command make them read+write, Subversion could keep track of which
>> files had been edited and significantly speed up status, diff, commit,
>> etc. It would make svn usable on projects where working on only
>> portions of a large tree is not practical.
>
> Replace "svn edit" with "svn lock" and don't you have the same basic
> feature (minus the potential speedup for the status command) ???
>
No, because 'svn lock' prevents others from committing. The original
poster said he doesn't want to disable concurrency, he just wants
people to have to declare their intent to edit.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: read-only checkouts
Posted by Scott Palmer <sc...@2connected.org>.
On Apr 2, 2005, at 12:54 PM, Josh Pieper wrote:
> I think one of the advantages of this declared edit feature is that it
> allows status/diff gathering to be blazingly fast. 'svn status' can
> take absurdly long periods of time on large working copies. If there
> were an option to have read-only checkouts and have a 'svn edit'
> command make them read+write, Subversion could keep track of which
> files had been edited and significantly speed up status, diff, commit,
> etc. It would make svn usable on projects where working on only
> portions of a large tree is not practical.
Replace "svn edit" with "svn lock" and don't you have the same basic
feature (minus the potential speedup for the status command) ???
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: read-only checkouts
Posted by Aniruddha Apte <an...@gmail.com>.
Our users *would* really love status'es and commits to be blazingly
fast. For example, for one of our trees if the import contained 4734
files, a WC of the same contains 17995 files. No wonder status and
commit take forever. I can see 2 benefits of working-copy changesets
(changelists in Perforce lingo)...
1. Users can segregate files they are currently working on into
change-sets for much better bug-fix management. In many environments
certain file are never committed but modified temporarily for
development purposes - these can be put into a "Don't checkin"
changeset.
The developer needn't sift through all modified files when the time
comes to check-in fix for a particular bug - just check-in that
changeset.
2. Status and commit would be *very* fast. In fact, contents of the
changeset would be the status.
regards,
-anir.
On Apr 2, 2005 11:24 PM, Josh Pieper <jj...@pobox.com> wrote:
> I think one of the advantages of this declared edit feature is that it
> allows status/diff gathering to be blazingly fast. 'svn status' can
> take absurdly long periods of time on large working copies. If there
> were an option to have read-only checkouts and have a 'svn edit'
> command make them read+write, Subversion could keep track of which
> files had been edited and significantly speed up status, diff, commit,
> etc. It would make svn usable on projects where working on only
> portions of a large tree is not practical.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: read-only checkouts
Posted by Josh Pieper <jj...@pobox.com>.
Ben Collins-Sussman wrote:
>
> On Apr 2, 2005, at 9:07 AM, Patrick Hanna wrote:
>
> > it just prevents a user from accidentally modifying some portion of
> >the source because they have not explicitly checked out that file for
> >editing.
>
> I don't understand why this is a problem, or what great catastrophe
> you're trying to prevent. As you said, it's not about locking files,
> it's about forcing users to "declare" the files they intend to change.
>
> My understanding is that some systems (like clearcase or perforce)
> behave this way, but I don't suspect Subversion will ever grow such a
> feature. The 'svn status' command shows exactly what you've edited.
> If you can teach users declare the files they want to edit, it seems
> just easy to to teach them to run 'svn status' early and often, and
> especially before running 'svn commit'.
I think one of the advantages of this declared edit feature is that it
allows status/diff gathering to be blazingly fast. 'svn status' can
take absurdly long periods of time on large working copies. If there
were an option to have read-only checkouts and have a 'svn edit'
command make them read+write, Subversion could keep track of which
files had been edited and significantly speed up status, diff, commit,
etc. It would make svn usable on projects where working on only
portions of a large tree is not practical.
-Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: read-only checkouts
Posted by Ben Collins-Sussman <su...@collab.net>.
On Apr 2, 2005, at 9:07 AM, Patrick Hanna wrote:
> it just prevents a user from accidentally modifying some portion of
> the source because they have not explicitly checked out that file for
> editing.
I don't understand why this is a problem, or what great catastrophe
you're trying to prevent. As you said, it's not about locking files,
it's about forcing users to "declare" the files they intend to change.
My understanding is that some systems (like clearcase or perforce)
behave this way, but I don't suspect Subversion will ever grow such a
feature. The 'svn status' command shows exactly what you've edited.
If you can teach users declare the files they want to edit, it seems
just easy to to teach them to run 'svn status' early and often, and
especially before running 'svn commit'.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: read-only checkouts
Posted by Patrick Hanna <pa...@openwave.com>.
It appears that "locking" the file makes it so that other users are
unable to edit the file. I was looking more for a way to essentially
"sync" your copy of the repository so you can build, etc. but when you
want you actually edit a file, you can explicitly checkout the file for
editing. This does not mean that other people can't do the same, it just
prevents a user from accidentally modifying some portion of the source
because they have not explicitly checked out that file for editing. This
sounds like more of a client-side feature in that the client can get a
copy of the repository but make all the files read-only and changes to
those files will only be commited if the file is checked out for
editing. Does that help explain the issue any clearer?
Thanks,
Patrick
Patrick Burleson wrote:
>On Apr 1, 2005 2:03 PM, Patrick Hanna <pa...@openwave.com> wrote:
>
>
>>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,
>>
>>Patrick
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>>For additional commands, e-mail: users-help@subversion.tigris.org
>>
>>
>>
>>
>
>I think you are going to want to wait until Subversion 1.2, which will
>include locking of files, which is essentially what you want.
>
>Patrick
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: read-only checkouts
Posted by Patrick Burleson <pb...@gmail.com>.
On Apr 1, 2005 2:03 PM, Patrick Hanna <pa...@openwave.com> wrote:
> 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,
>
> Patrick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
I think you are going to want to wait until Subversion 1.2, which will
include locking of files, which is essentially what you want.
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: read-only checkouts
Posted by Brooke Smith <no...@optusnet.com.au>.
Ok well yes then. I'm just highlighting problems that people may have
with the locks. I don't know what you could do about them though (How
do other VCSs handle this situation?).
Cheers,
Brooke
On 09/04/2005, at 12:32 AM, Ben Collins-Sussman wrote:
>
> On Apr 7, 2005, at 5:51 PM, Brooke Smith wrote:
>>
>> 2. User tries to open the 'needs-lock' file
>> 3. TSVN locks the file (if it isn't already and in which case it will
>> display an error message) and opens the file. The user isn't aware.
>>
>
> Sure, this works assuming that the user double-clicks the file from
> windows explorer.
>
> But what if the user runs MS Word, then does File->Open?
>
> Or what if some power-user opens a command prompt and runs
> "winword.exe file.doc"?
>
> In this case, windows explorer isn't even *aware* that a file got
> opened.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---
In a world without walls or fences,
what's the need for Gates and Windows?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: read-only checkouts
Posted by Ben Collins-Sussman <su...@collab.net>.
On Apr 7, 2005, at 5:51 PM, Brooke Smith wrote:
>
> 2. User tries to open the 'needs-lock' file
> 3. TSVN locks the file (if it isn't already and in which case it will
> display an error message) and opens the file. The user isn't aware.
>
Sure, this works assuming that the user double-clicks the file from
windows explorer.
But what if the user runs MS Word, then does File->Open?
Or what if some power-user opens a command prompt and runs "winword.exe
file.doc"?
In this case, windows explorer isn't even *aware* that a file got
opened.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: read-only checkouts
Posted by Brooke Smith <no...@optusnet.com.au>.
Lets look at this from a different perspective.
A tool like TSVN may work like this:
1. The user ticks a preference to say yes to 'always lock file for
writing'. The preferences are of course global and the user never has
to venture here again.
2. User tries to open the 'needs-lock' file
3. TSVN locks the file (if it isn't already and in which case it will
display an error message) and opens the file. The user isn't aware.
The alternative and error-filed / confusing view of this is:
The user is using the SVN command-line tools
1. The user in a terminal creates a WC with 'svn co svn://....'
2. User tries to open the 'needs-lock' file and it opens (read only)
3. Depending on the user's skill level, they may either be confused or
issue a "Doh!" (or be frustrated that they didn't know it was marked
'needs-lock')
In the first scenario, the Client tool is protecting the user. In the
second scenario, the svn command-line tools are much lower-level and
would never auto-lock a file. I guess the Developer's view on this is
that those who use the CL client will be aware of the problem
immediately. But maybe not, since authorisation may also make a
resource read-only.
My point here is that a higher-level client like TSVN may gracefully
handle the 'needs-lock' property but that the lower-level CL client
won't and there should be some appropriate feedback mechanism to
highlight the fact that the file is marked 'needs-lock'.
Brooke
On 05/04/2005, at 11:20 AM, Ben Collins-Sussman wrote:
>
> On Apr 4, 2005, at 5:02 PM, Brooke Smith wrote:
>
>> Hi Ben,
>>
>> The two step process is 1. User wants to edit file, 2. User opens
>> file but finds its read-only (confusion possibly reigns) 3. If they
>> understand the issue they issue they lock the file and edit it. Step
>> 2 may not occur. The 2 step process is lock and edit.
>>
>> I was thinking about this from the documentation teams POV (or the
>> graphic illustrators). The non-techo types basically. These people
>> might think that they just want to edit the file, not take this extra
>> step which they don't understand. I answered my own question in my
>> last mail and said that the client, such as TortoiseSVN could provide
>> the option and automatically set the lock before opening files that
>> have that property attached.
>>
>
> Sorry, I'm still not understanding. How can step 2 not occur?
> They're not going to notice that the file is read-only? That's
> certainly possible... there are bad programs out there which flat-out
> ignore read-onlyness. We call that 'hijacking'.
>
> But the problem is that *nothing* can prevent hijacking, not even your
> TortoiseSVN idea above. The only thing that can prevent it is if the
> working-copy were implemented at the OS filesystem level -- and that's
> how clearcase works. :-)
>
>
---
In a world without walls or fences,
what's the need for Gates and Windows?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: read-only checkouts
Posted by Ben Collins-Sussman <su...@collab.net>.
On Apr 4, 2005, at 5:02 PM, Brooke Smith wrote:
> Hi Ben,
>
> The two step process is 1. User wants to edit file, 2. User opens file
> but finds its read-only (confusion possibly reigns) 3. If they
> understand the issue they issue they lock the file and edit it. Step
> 2 may not occur. The 2 step process is lock and edit.
>
> I was thinking about this from the documentation teams POV (or the
> graphic illustrators). The non-techo types basically. These people
> might think that they just want to edit the file, not take this extra
> step which they don't understand. I answered my own question in my
> last mail and said that the client, such as TortoiseSVN could provide
> the option and automatically set the lock before opening files that
> have that property attached.
>
Sorry, I'm still not understanding. How can step 2 not occur? They're
not going to notice that the file is read-only? That's certainly
possible... there are bad programs out there which flat-out ignore
read-onlyness. We call that 'hijacking'.
But the problem is that *nothing* can prevent hijacking, not even your
TortoiseSVN idea above. The only thing that can prevent it is if the
working-copy were implemented at the OS filesystem level -- and that's
how clearcase works. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: read-only checkouts
Posted by Brooke Smith <no...@optusnet.com.au>.
Hi Ben,
The two step process is 1. User wants to edit file, 2. User opens file
but finds its read-only (confusion possibly reigns) 3. If they
understand the issue they issue they lock the file and edit it. Step 2
may not occur. The 2 step process is lock and edit.
I was thinking about this from the documentation teams POV (or the
graphic illustrators). The non-techo types basically. These people
might think that they just want to edit the file, not take this extra
step which they don't understand. I answered my own question in my
last mail and said that the client, such as TortoiseSVN could provide
the option and automatically set the lock before opening files that
have that property attached.
Cheers,
Brooke
On 03/04/2005, at 2:00 PM, Ben Collins-Sussman wrote:
>
> On Apr 2, 2005, at 4:51 PM, Brooke Smith wrote:
>
>> auto-locks (or a property to do) so that whenever someone works on
>> some file, it is automatically locked.
>
> Sorry, I don't quite understand this idea. Do you understand how the
> 'svn:needs-lock' property works? (I can't tell if you do?)
>
> If a file is marked with 'svn:needs-lock', then it's read-only all of
> the time. In order to make it read-write, the user must 'svn lock' it
> first. So I'm not sure what "two step" process you're talking
> about...?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---
In a world without walls or fences,
what's the need for Gates and Windows?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: read-only checkouts
Posted by Ben Collins-Sussman <su...@collab.net>.
On Apr 2, 2005, at 4:51 PM, Brooke Smith wrote:
> auto-locks (or a property to do) so that whenever someone works on
> some file, it is automatically locked.
Sorry, I don't quite understand this idea. Do you understand how the
'svn:needs-lock' property works? (I can't tell if you do?)
If a file is marked with 'svn:needs-lock', then it's read-only all of
the time. In order to make it read-write, the user must 'svn lock' it
first. So I'm not sure what "two step" process you're talking
about...?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: read-only checkouts
Posted by Brooke Smith <no...@optusnet.com.au>.
Hi Ben,
There is the property "svn:needs-lock", but were there any discussions
of having auto-locks (or a property to do) so that whenever someone
works on some file, it is automatically locked. Or do you feel that
the repository hooks will be sufficient (can these put a lock on?)?
I'm thinking that a 2 step process to edit a file will not be well
received by many (non-techie) users. The other alternative, is that
clients, such as TortoiseSVN might handle this for the user. Sorry for
the noise, I'm thinking out loud, though this question could well come
up in the near future.
Well done on 1.2. Subversion has been well received and is starting to
be used at Boeing Australia.
Cheers,
Brooke
On 02/04/2005, at 7:02 AM, Ben Collins-Sussman wrote:
>
> On Apr 1, 2005, at 1:03 PM, Patrick Hanna wrote:
>
>> 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,
>>
>
> Yes, see the upcoming 'locking' feature in svn 1.2. The first release
> candidiate tarball (1.2-rc1) will hopefully be out on Monday. Here's
> an early draft of the release notes:
>
> http://svn.collab.net/repos/svn/trunk/www/svn_1.2_releasenotes.html
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---
In a world without walls or fences,
what's the need for Gates and Windows?
Re: read-only checkouts
Posted by Ben Collins-Sussman <su...@collab.net>.
On Apr 1, 2005, at 1:03 PM, Patrick Hanna wrote:
> 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,
>
Yes, see the upcoming 'locking' feature in svn 1.2. The first release
candidiate tarball (1.2-rc1) will hopefully be out on Monday. Here's
an early draft of the release notes:
http://svn.collab.net/repos/svn/trunk/www/svn_1.2_releasenotes.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org