On Wed, Jan 22, 2003 at 05:07:38PM -0800, Sung Kim wrote:
...
The general DeltaV client, dvc(DeltaV client) will have several version
control commands like svn or cvs:
- dvc import
- dvc checkout
- dvc commit
- dvc update
- dvc branch
- dvc merge
- dvc add
- dvc delete
These commands seem to imply that you're going to be using client-side
workspaces in your client. And no server-side workspace support. Right?
...
I think basic commands(import, checkout, commit and update) could work with
server that support only basic versioning(linear versioning). Subversion
uses MKACTIVITY and MERGE to checkout(commit) and do you think we can
implement the basic commands without MKACTIVITY and MERGE support which are
advanced versionig package methods.
Well, Subversion's server model pretty much requires that you using working
resources. That is: no checkout in place. That's because the public URL
always represents the latest version, so it shouldn't be the location where
people make edits to the file.
Now... I do think that we could skip the MKACTIVITY and MERGE, which then
implies that you would lose the transactional semantics of checking in
multiple changes. That is, you could do a CHECKOUT to get a working resource
for a file, PUT to that working resource, then CHECKIN the resource. Under
the covers, we would manufacture an SVN txn at CHECKOUT time, which is then
encoded in the working resource URL, which is then used for the later
operations.
Depending on the types of operations, you *can* get certain types of atomic
behavior. For example, you could CHECKOUT a collection, and then add and
remove a bunch of items from inside the resulting working collection. When
you do a CHECKIN on the collection, everything else goes in with it.
Also subversion expects some custom features from the server and the
subversion server is not a general DeltaV server.
Is there any reason that subversion uses some custom features?
We need them to get certain types of functionality. In some cases, there is
a DeltaV equivalent, but doing that would be more cumbersome at this time.
Our custom features are built within the protocol, but foreign servers won't
understand the report types, custom properties, or custom headers that we
use.
For example, here are two reports we use:
svn:update-report
svn:log-report
Most servers will simply return an error, indicating they don't support
those report types.
Some custom headers:
X-SVN-VR-Base: used to indicate the base version of a file, enabling the
server to send a diff against that base; servers that don't
understand this header will simply send a fulltext file.
X-SVN-Options: used to trim the MERGE response; DeltaV servers would send
a longer response which the client would just throw away.
etc.
If you've got some specific questions, then ask away. Happy to help.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:08:28 2006