Anyone want to take on the command-line client task? (It could be
multiple people too.)
This would require lots of familiarity with the existing CVS
command-line client, since we're trying to be similar to it in spirit
at least, and also familiarity with the features Subversion provides.
You should be comfortable with cyclical development, as rounds of
commentary and useability testing will definitely be part of the job.
I guess the first subtask would be to write up a document describing
the user interface in detail, and then not losing heart as you watch
it inevitably get picked apart by this list. :-)
This program will mostly make calls into libsvn_client, and you would
have lots of influence over the API that libsvn_client provides --
i.e., what's there right now is only an initial implementation,
certainly not gospel.
Any takers?
Hopefully,
-Karl
P.S. Attached is an old outline of a spec for the command-line client,
written by Jim Blandy. It's probably a good place to start, but also
is not gospel of course.
------- Start of forwarded message -------
Date: Fri, 13 Oct 2000 11:02:01 -0500
Message-Id: <200010131602.LAA17761@savonarola.red-bean.com>
From: Jim Blandy <jimb@savonarola.red-bean.com>
To: Karl Fogel <kfogel@red-bean.com>
Subject: very old command-line stuff
* The Subversion Unix Client
We need:
- enhanced patch files (emulate Bitkeeper's format?)
- way to refer to common ancestor of two branches
** command syntax
LOCAL-DIR: name of a directory on the local filesystem
LOCAL-FILE: name of a file
LOCAL-NAME: either LOCAL-DIR or LOCAL-FILE
REMOTE-DIR: something of the form HOST:REPO:DIR
REMOTE-FILE: something of the form HOST:REPO:FILE
REMOTE-NAME: either REMOTE-DIR or REMOTE-FILE
Also --- if you omit HOST:REPO, and just write :DIR or :FILE,
that takes the HOST and REPO and the base directory from the
current working directory.
DIR: either a LOCAL-DIR or a REMOTE-DIR
FILE: either a LOCAL-FILE or a REMOTE-FILE
NAME: either a LOCAL-NAME or a REMOTE-NAME
If a non-remote filename doesn't refer to something in a working
directory, Subversion signals an error. However, you can change `NAME'
to `-plain NAME', and Subversion will go ahead and munge NAME, and not
worry about recording its history. (I guess it should make .~n~ files.)
NAME:N refers to version N of NAME, or the difference between
versions N-1 and N of NAME, depending on context.
NAME:N1:N2 refers to the difference between versions N1 and N2 of NAME.
If N is "base", then NAME:N refers to the base version of NAME.
If N is "tip", then NAME:N refers to the most recent version of NAME.
If N is "here", then NAME:N refers to the present sources. This is
only useful in forms using two version numbers, since NAME:here
is equivalent to NAME.
Thus, `.:base:tip' is the set of atoms in the repository waiting to be
merged into your directory. And `.:base:here' is the set of changes
in your working directory waiting to be committed.
sub add [-r] NAME...
sub mkdir NAME...
sub rm [-r] NAME...
sub mv NAME... DIR
sub mv NAME1 NAME2
sub cp [-r] NAME... DIR
sub cp [-r] NAME1 NAME2
`sub add', `sub rm', and `sub cp' complain if an argument is a
directory, and `-r' isn't given. Just as a sanity check.
sub repo CMD ...
Same as `sub CMD ...', except that filenames are taken to apply to
the current directory's repository, by default.
sub checkout HOST:REPO:NAME
Equivalent to `sub cp -r HOST:REPO:NAME -plain .'.
sub import NAME1 HOST:REPO:NAME2
Equivalent to `sub cp -r -plain NAME1 HOST:REPO:NAME2'.
sub apply NAME1[:N1[:N2]] NAME2
Apply changes specified by NAME1[:N1[:N2]] to NAME2.
If NAME1 form, then
If NAME1:N1 form, then the change applied is the difference between
versions N1-1 and N1.
If NAME1:N1:N2 form, then the change applied is the difference between
versions N1 and N2 of NAME1.
sub commit [FILE...]
If omitted, FILE... defaults to `.'.
For each FILE, do `sub apply FILE:base:here FILE:base'.
sub update [FILE...]
If omitted, FILE... defaults to `.'.
For each FILE, do `sub apply FILE:base:tip FILE'.
sub vert LOCAL-DIR REMOTE-DIR
Turn LOCAL-DIR into a working directory with the tip of REMOTE-DIR
as its base version, by sticking in the appropriate control files.
sub script CMD ...
The same as "sub CMD ...", except that the rules for names are a
little different, to help make scripts more reliable. Colons lose
their special meaning, so if the names of actual files processed by
the script contain colons, things will still work.
Instead of FOO:N, write -name:n FOO N
Instead of FOO:N:M, write -name:n:m FOO N M
Instead of HOST:REPO:FOO, write -remote:name HOST:REPO FOO
and so on.
If you actually do want colons in a name parsed normally (to handle an
argument from a user, for example), you can write `-parsed NAME'.
Haven't revised these yet:
sub diff FILE ...
sub diff -r N FILE ...
sub diff -r N1 -r N2 FILE ...
sub diff -r DIR:N FILE ...
sub diff -r DIR1:N1 -r DIR2:N2 FILE ...
sub diff -r N1 -r N2 FILE:N3 ...
sub log
sub fix-log
------- End of forwarded message -------
Received on Sat Oct 21 14:36:11 2006