On Tue, Oct 17, 2000 at 01:26:07PM -0500, Jim Blandy wrote:
>...
> * It seems kind of archaic to type:
>
> svn -d REPO-SPEC checkout MODULE
>
> This splits the information `what am I checking out' across two
> different places. It would be nicer to simply name the thing you're
> checking out, using some appropriate noun clause. For remote things,
> URL's are the natural kind of noun clause:
>
> svn checkout http://subversion.tigris.org/repo/subversion
>
> I don't know if this is exactly the DAV way; maybe Greg can provide a
> more realistic example. But the important idea is that the syntax
> should be:
>
> svn checkout THING
This is *exactly* how I would envision this working, and is what the
"ra-dav-test" does. You give it a URL and it checks the thing out. It needs
an argument revamp now that WC is working well -- I think it currently
requires a local dir to be specified or somesuch, and it creates an extra
level of dir when it shouldn't.
Regardless: in the example above, I would expect it to work exactly as
typed, and that a directory named "subversion" would be created in the
current dir. (e.g. take the last component as the top-level dir name)
> * Given Subversion's idea that the repository is just a versioned
> filesystem, it makes sense to allow some operations directly on the
> repository. For example, if I want to copy a tree, so I can start
> work on a separate branch of development, I shouldn't have to check
> out this huge tree, copy a big section of it, and then commit that.
>
> Just as I can say:
>
> svn cp SOURCE DEST
>
> to copy something in my working directory, I should be able to use
> URL's for SOURCE and / or DEST, and have the right thing happen. It's
> the same idea behind rcp / scp: instead of providing one command for
> downloading, and a separate command for uploading, just provide a
> syntax for referring to files elsewhere, and let the names tell you
> how the data needs to flow.
>
> Since we don't support inter-repository branching yet, we would
> require for now that when SOURCE or DEST are remote, they must refer
> to the same repository.
This should be doable. The above command would be a single COPY request over
the network.
Now... I do have to say that we aren't going to be close to that point for a
good while. Within the framework of DAV, a COPY on a versioned collection
implies auto-versioning. For the moment, I'm avoiding that big time, and
wrapping all changes into a DAV "activity". An activity corresponds to an FS
"transaction". So... to do autoversioning, the server is going to have a
good chunk of work. Before we get there, I would imagine the client would
transform the above command into a sequence of MKACTIVITY, CHECKOUT
<parent-of-DEST>, COPY <SOURCE> to <DEST>, MERGE <activity>.
But... neither here nor there. Within the DAV framework, the above command
is totally fine from a semantic standpoint and we can/will be able to
support it at some point [for 1.0? post 1.0? hard to say... my pragmatism
wants to cut auto-versioning for SVN 1.0.. but we can do the long route via
activities, surely]
What does this mean? There are a *lot* of things that we can do without a
working copy. In fact, the DAV model is designed to operate *without* a
local copy. The DeltaV guys have had a few re-thinks based on our local,
working copy model.
Theoretically, all the data that is kept in the SVN subdir (except for the
"entries" file) could be stored on the server as part of a user's
"workspace". Any kind of operation imaginable on the local copy is doable on
the server, provided we support *enough* of the complete DAV model.
Keyword: "enough". mod_dav_svn 1.0 (the guts of our DAV support on the
server) will support what Subversion *needs*. We won't be a true and
complete DeltaV server. Well, I shouldn't say that... maybe there will be
time to build more in there, but my focus is on a DeltaV subset at this
point. When that is DONE, then we can look at becoming a true and proper
DeltaV server.
etc etc.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:11 2006