I have been looking over this thread and have a few questions regarding the
idea of reserved checkouts. I am sure I don't fully understand the SVN
implemetation being discussed.
Will all the SVN clients know, in real time, that file.doc has just been locked
in SVN workarea ABC? If a main benefit of having reserved checkouts is to be
able to prevent two people (or more approprately, two workareas) from modifying
the same non-mergeable file at the same time (because enforcing locks at commit
time is to late, work already has been done on the non-mergable file in both
workareas), will svn be able to handle reserved checkouts in this manner? If
not, then what is the goal/functionality/purpose of the reserved checkout/lock
functionality being proposed here with SVN?
Are we talking about SVN providing readonly workareas, requiring a 'cvs edit'
like functionality to make files writeable? Maybe that could work, but if it is
possible to break a lock in one workarea from another workarea or non-workarea
(SVN will know which workarea has the lock on the file, right?), how will SVN
notify the SVN workarea that had the lock, that the lock has been broken (so
the client can report that the file is now unlocked and is now readonly in that
workarea)? Okay, in this situation, what happens to local edits on that file in
that SVN workarea that got unreserved ('cvs unedit' reversion of the file)?
If a workable reserved checkout implementaion is worked out, can it be made
required for certain file types, while allowing CVS style concurrency on
mergable files?
Thanks,
Mark
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 2 14:37:38 2002