>> These things are on the post-1.0 to-do list (check the "post-1.0"
issues in the Subversion issues list). If >> you find one not there,
let us know
I think "Locking" (also called "Reserved Checkout") should be stated on
the main Subversion home page (http://subversion.tigris.org/) as a
post-1.0 feature. It is on the issue list
(http://subversion.tigris.org/issues/show_bug.cgi?id=533) but this is
almost a first asked question for many users and is a critical feature
supported by practically every other VC system (yes, even CVS).
For me it's a killer. It's not a Subversion technology issue, it's a
client technology issue. There are tools out there with source control
models that do not fit Subversion's model and to use Subversion as a
back-end absolutely require locking. Most tools which use Microsoft's
SCCAPI assume locking and will fail without it. There are also tools
which store important data in binary files which may be edited by
multiple users.
How about coming to some decision about this and adding a bullet point
to the main Subversion home page, something like:
* Support for locking (reserved checkouts)
Subversion will support the marking of a file as 'locked by another
user.' This is to support client tools which require locking, and to
provide a mechanism to prevent concurrent updates to files which
cannot be safely merged. The exact implementation is yet to be
decided.
The obvious example for me of both the points above is Visual FoxPro,
which uses the SCCAPI interface, and stores some source code components
in database tables. VFP knows which file types can be safely merged, and
allows simultaneous checkouts of those ones, but not of the others.
Worse, these files come in pairs and must be checked out/in *togther*. I
can probably get around the SCCAPI problems (Subway?), but unfortunately
I can't put the VFP projects into Subversion unless I can guarantee
through some means that only one developer at a time will ever modify
the dangerous files. Because of svn's atomic commits, we'll be spared
the consequences of one half of a file pair being checked in and the
other not, but we could still be left with one developer unable to
commit a couple of hours work because another made a tweak somewhere.
(I'm not one of those late adopters who will "dig their heels in and
insist that they cannot move to SVN
becuase it does not have locking" - there are Delphi and Java projects
in Subversion now - but I'm kind of stuck).
The other problem, which is not really the Subversion team's
responsibility, but is a serious block to wider adoption of Subversion,
is client tool support. I have a couple of web projects which are
remaining in SourceSafe for the forseeable future, because Dreamweaver
cannot talk to subversion satisfactorily.
Ironically Dreamweaver should be a doddle - it supports a pluggable
source control API. But I can't use a native svn plugin (there isn't
one), the SCCAPI interface (Subway is not ready for prime time), or even
WebDAV (for reasons discussed on this list. This last is really
Macromedia's fault - is DW2004 any better?)
Incidentally, anyone got any good stuff on SCCAPI support for
Subversion? The NDA required to write one has made this very difficult
in the past. Subway (http://nidaros.homedns.org/subway/) seems to have
gone very quiet.
- Walter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 3 23:18:39 2003