You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mo DeJong <su...@bayarea.net> on 2001/09/13 01:51:06 UTC
update vs status, where should local mods be displayed?
Hi all.
I have a quick question about local modifications and where
they should be displayed. I have noticed that `svn update`
does not display the names of files with local mods.
It will display a U when a new rev is pulled down,
but it mentions nothing about a local modification,
a local deletion, or a local addition. This is quite
different from how CVS works so I fear it may take quite
some getting used to. I do like the conceptual separation
between a `svn status` and a `svn update` but I really
get the feeling subversion would be more useful if
the output of these two commands were a bit different.
For example, I often do a `cvs update` to make sure everything
is up to date and to figure out which files to pass to a commit
subcommand.
To do this with subversion, I could run update and then status,
and sift through the (very long) output of the status subcommand
to figure out which files were locally modified/added/deleted.
% svn update
% svn status > status
% grep "M " status
M 95 ( 95) ./configure.in
M 95 ( 95) ./gen-make.py
% grep "A " status
A 0 ( 95) ./buildcheck.sh
% svn commit configure.in gen-make.py buildcheck.sh
While that is certainly doable, it is clearly not as easy as
running `cvs update`.
I did find this -M flag that can be passed to the status subcommand
(there was no mention of this flag in clients/cmdline/README).
When passed, the svn_cl__print_status_list function will only print
those entries that have been "modified".
% svn -M status
M 95 ( 95) ./autogen.sh
M 95 ( 95) ./build.conf
M 95 ( 95) ./configure.in
M 95 ( 95) ./gen-make.py
My first reaction to this is that the definition of modified used in
svn_cl__print_status_list should include those files that are
locally added or deleted. That would certainly make the output more
useful when the -M flag is passed.
(Possible output)
% svn update
% svn -M status
M 95 ( 95) ./configure.in
M 95 ( 95) ./gen-make.py
A 0 ( 95) ./buildcheck.sh
% svn commit configure.in gen-make.py buildcheck.sh
Of course, the fact that a -M flag exists in the first place just
makes me think that the default output of the status command is
simply too verbose. Perhaps the status command should only print
info about files that have actually changed when recursing.
For example, here is a quick snip from the output of status
on my machine:
_ 95 ( 95) ./ac-helpers/install.sh
_ 95 ( 95) ./ac-helpers/svn-apache.m4
_ 95 ( 95) ./ac-helpers/svn-macros.m4
M 95 ( 95) ./autogen.sh
M 95 ( 95) ./build.conf
A 0 ( 95) ./buildcheck.sh
What information does the first three lines really provide?
Can't we communicate that the install.sh, svn-apache.m4,
and svn-macros.m4 files are up to date and have not been
changed by not printing a line of output for them?
This can be quite a problem even for a small repo
with hundreds of entries. Sifting through thousands
of entries worth of output would be even worse.
What I am suggesting is that the default output of the
status command should not display every file. Instead
the default should display info for locally modified
file, locally added files, and locally deleted files
(I assume modified props would also apply here). We
could add a `svn status -v` option to print out the
really verbose output that is currently displayed.
On a related but separate note, should the `svn update`
command do something similar? It currently ignores
local mods, adds, and deletes.
I am certainly willing to work on implementing these
changes, I just want to get some feedback from the
group before starting down this path.
cheers
Mo DeJong
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update vs status, where should local mods be displayed?
Posted by cm...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> I agree, right now "-M" is only printing (M)odified and (C)onflicted
> files. But I believe that scheduling an object for (A)ddition,
> (D)eletion or (R)eplacement should show up with this flag as well.
> They're all local modifications in their own way. I can make this
> change if others agree.
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update vs status, where should local mods be displayed?
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Sep 13, 2001 at 05:13:41PM -0500, Ben Collins-Sussman wrote:
> Joe Orton <jo...@manyfish.co.uk> writes:
>
> > Speaking as someone who is often many hops from the server, having an
> > "svn status" command which is a local thing is a genuine gift from the
> > gods.
>
> Are you aware that 'svn status' already works if no network is
> available? It just prints a '?' for the repository revision.
It still tries, which can be quite problematic. How would you feel if you
wanted the status of WC, but every time you tried, your laptop's autodial
mechanism popped up a dialog in your face asking for your PPP password and
then tried to dial your modem? After a 10 second timeout when it realized
there was no dialtone, then it would finally give up, and *then* you would
get your status information.
There is a big benefit to *knowing* that something will not smack the
network. That you can use it quickly and easily. And that it gives you just
the information you're asking for, and no more.
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
Re: update vs status, where should local mods be displayed?
Posted by Ben Collins-Sussman <su...@collab.net>.
Joe Orton <jo...@manyfish.co.uk> writes:
> Speaking as someone who is often many hops from the server, having an
> "svn status" command which is a local thing is a genuine gift from the
> gods.
Are you aware that 'svn status' already works if no network is
available? It just prints a '?' for the repository revision.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update vs status, where should local mods be displayed?
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Thu, Sep 13, 2001 at 02:07:07PM -0700, Greg Stein wrote:
> Case (1) is more common, I'd say. How often do people want to see what is
> new, but *not* pull it down? IMO, the typically pattern is:
>
> (edit, edit, edit)
> $ svn status
> (figure out commit msg)
> $ svn commit
> $ svn up
> (repeat)
This is exactly how I've been using svn (hacked so that "svn status" ==
"svn status -M", and getting rid of the remote repos revision stuff)
Speaking as someone who is often many hops from the server, having an
"svn status" command which is a local thing is a genuine gift from the
gods.
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update vs status, where should local mods be displayed?
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Stein <gs...@lyra.org> writes:
> Well... that is enuf for my analysis. Basically, I think "svn status" should
> default to the -M switch. --verbose gives you info on all files. No real
> answer for "check the server for true update info."
See the my last post on this thread. I believe that 'svn status'
should show us information *simultaneously* about local mods and
impending patches. We use the first column to describe an impending
commit, and a different column to describe an impending update.
But yeah, I agree. 'svn status' with no switches at all should filter
out all the "boring" items that have no flags set. If you want to see
every file, add a verbose switch.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update vs status, where should local mods be displayed?
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Sep 13, 2001 at 02:10:22PM -0500, Ben Collins-Sussman wrote:
>...
> There are two common use-cases for 'svn status', I believe.
>
> 1. To see local mods
>
> The user wants to know exactly what to commit, or what would be
> committed. No other clutter.
>
> 2. To examine 'up-to-dateness'.
>
> The user wants to know which files are out-of-date. This means seeing
> local revision numbers on files, but *mostly* seeing out-of-date
> flags. The user can then predict exactly what will be patched when
> 'svn up' is run.
Agreed.
Today, "svn status" can do (1) (but it isn't the default), and it cannot do
(2). It can give you a hint that *something* is going to be updated because
the server rev is newer than your files. But it can't do (2).
> The heart of the this debate is: "which use case is more common?"
> Whichever is more common -- that should be the default.
Case (1) is more common, I'd say. How often do people want to see what is
new, but *not* pull it down? IMO, the typically pattern is:
(edit, edit, edit)
$ svn status
(figure out commit msg)
$ svn commit
$ svn up
(repeat)
> On this issue, my own experience may be skewed;
I believe it is :-)
To actually do case (2), we need to send an update report to the server and
then specially process the results -- we skip the whole "fetch" part of the
report processing. Effectively, it would "cvs -n up" but we'd make it a part
of the "svn status" subcommand.
Hmm. I believe we have a table of four commands:
Show actual update activity?
YES NO
All files 1 2
Affected files 3 4
The -M switch is flipping us between options (2) and (4). We have nothing
for options 1,3 (until we do the special report processing, per above). But
if we *do* the modified-report, then how do we differentiate the four cases?
I like Mo's idea of tossing -M and simply using different levels of
verbosity. And -M stops making sense once we change the default to be -M. If
we assume --verbose gives us all the files, then what flag hits the server
for the extended information? Is it a flag, or a separate subcommand?
How about these command lines for the 4 cases:
1) svn status --will-update --verbose
2) svn status --verbose
3) svn status --will-update
4) svn status
(need better names for will-update)
I'm tempted to say that if you want to see status on your local changes,
then to use "svn status". If you want to know about what will happen with an
update, then use "svn update". But that puts us back into the CVS mode.
Well... that is enuf for my analysis. Basically, I think "svn status" should
default to the -M switch. --verbose gives you info on all files. No real
answer for "check the server for true update info."
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
Re: update vs status, where should local mods be displayed?
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Thu, Sep 13, 2001 at 05:12:12PM -0500, Ben Collins-Sussman wrote:
> Joe Orton <jo...@manyfish.co.uk> writes:
>
> > I don't understand why people want to overload the "status" command with
> > doing updatey things. "status" should show me the status of the WC - end
> > of story. If you want some kind of "will an update change my WC"
> > command, add a --dry-run to "update", like make has, or something.
>
> You don't think a "status report" on your working copy should tell you
> what's out of date? CVS's status report certainly does, and I don't
> think that's a misfeature.
Oh, really, maybe I am just off in my own little world here, but I very
very definitely don't want "svn status" to go over the network. I think
this comes from having used CVS over a high-latency connection, where
the only way to find out this "which bits I changed" was to use "cvs
update" and wait half an hour while it goes and does its thing.
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update vs status, where should local mods be displayed?
Posted by Mo DeJong <su...@bayarea.net>.
On Fri, 14 Sep 2001 09:11:06 -0400
Kevin Pilch-Bisson <ke...@pilch-bisson.net> wrote:
> On Fri, Sep 14, 2001 at 09:33:50AM +0200, Sander Striker wrote:
> > > -----Original Message-----
> > > From: Daniel Stenberg [mailto:daniel@haxx.se]
> > > Sent: 14 September 2001 09:15
> > > On 13 Sep 2001, Ben Collins-Sussman wrote:
> > >
> > > > > (1) what did I change?
> > > > >
> > > > > (2) what is out of date?
> > > >
> > > > If we split 1 and 2 into two different subcommands, what would they be
> > > > called? Could their output still be similar?
> > >
> > > .... and it would still be neat to have _one_ command that shows
> > > a combined output, as discussed previously. It doesn't necessarily take
> > > away the need for two different ones of course, but could be an option
> > > or something.
> >
> >
> > I'd like to see 'status' and 'lstatus' (local status) or 'status -l'
> > (--local).
> > status would be 1 and 2 combined, lstatus would be just 1.
> >
> > I think output could be similar.
> +1 for status -l/--local. Then if we just gave status, and the network wasn't
> available, we could print a warning, saying "Network not available, showing
> local modifications only."
I like this -l idea as well. A status command that does not touch the network
seems useful but not so useful as to deserver its own subcommand. The -l
flag is not currently being used although it is mentioned in the client README.
-l --local-dir Local; run only in current working directory.
Thing is, the src code currently uses 'n' for that option {"nonrecursive", 'n', 0}.
What is also strange about that is the fact that the README status that the
'n' option is meant to be a shortcut for the --dry-run long option (like CVS).
Whatever option we decide on, one thing to note is that we may need an option
to turn the "use the network" option back on. Me thinks some folks will set
`svn status --local` in ~/.svnrc but still want some way to override that on
the command line in case they do want to find out about pending updates.
cheers
Mo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update vs status, where should local mods be displayed?
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Fri, Sep 14, 2001 at 09:33:50AM +0200, Sander Striker wrote:
> > -----Original Message-----
> > From: Daniel Stenberg [mailto:daniel@haxx.se]
> > Sent: 14 September 2001 09:15
> > On 13 Sep 2001, Ben Collins-Sussman wrote:
> >
> > > > (1) what did I change?
> > > >
> > > > (2) what is out of date?
> > >
> > > If we split 1 and 2 into two different subcommands, what would they be
> > > called? Could their output still be similar?
> >
> > .... and it would still be neat to have _one_ command that shows
> > a combined output, as discussed previously. It doesn't necessarily take
> > away the need for two different ones of course, but could be an option
> > or something.
>
>
> I'd like to see 'status' and 'lstatus' (local status) or 'status -l'
> (--local).
> status would be 1 and 2 combined, lstatus would be just 1.
>
> I think output could be similar.
+1 for status -l/--local. Then if we just gave status, and the network wasn't
available, we could print a warning, saying "Network not available, showing
local modifications only."
>
> My $0.02,
>
> Sander
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
RE: update vs status, where should local mods be displayed?
Posted by Sander Striker <st...@apache.org>.
> -----Original Message-----
> From: Daniel Stenberg [mailto:daniel@haxx.se]
> Sent: 14 September 2001 09:15
> On 13 Sep 2001, Ben Collins-Sussman wrote:
>
> > > (1) what did I change?
> > >
> > > (2) what is out of date?
> >
> > If we split 1 and 2 into two different subcommands, what would they be
> > called? Could their output still be similar?
>
> .... and it would still be neat to have _one_ command that shows
> a combined output, as discussed previously. It doesn't necessarily take
> away the need for two different ones of course, but could be an option
> or something.
I'd like to see 'status' and 'lstatus' (local status) or 'status -l'
(--local).
status would be 1 and 2 combined, lstatus would be just 1.
I think output could be similar.
My $0.02,
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update vs status, where should local mods be displayed?
Posted by Daniel Stenberg <da...@haxx.se>.
On 13 Sep 2001, Ben Collins-Sussman wrote:
> > (1) what did I change?
> >
> > (2) what is out of date?
>
> If we split 1 and 2 into two different subcommands, what would they be
> called? Could their output still be similar?
... and it would still be neat to have _one_ command that shows a combined
output, as discussed previously. It doesn't necessarily take away the need
for two different ones of course, but could be an option or something.
--
Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update vs status, where should local mods be displayed?
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Stein <gs...@lyra.org> writes:
> I think I'm in agreement with Joe, and would certainly appreciate an "svn
> status" that is entirely local and only talks about what I've done in my WC.
>
> (1) what did I change?
>
> (2) what is out of date?
>
Okay, we all agree on these use cases. Case 1 is entirely local, and
case 2 requires network.
You guys seem to be advocating that we split these two tasks into
different subcommands; that being able to run case 1 sans network is a
huge huge deal, and thus justifies the split.
I'm not going to argue that it's important to keep the use-cases
combined; I only posted that exerpt from the spec because I had
assumed that we were all still at that original starting point. :-)
If we split 1 and 2 into two different subcommands, what would they be
called? Could their output still be similar?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update vs status, where should local mods be displayed?
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Sep 13, 2001 at 05:12:12PM -0500, Ben Collins-Sussman wrote:
> Joe Orton <jo...@manyfish.co.uk> writes:
>
> > I don't understand why people want to overload the "status" command with
> > doing updatey things. "status" should show me the status of the WC - end
> > of story. If you want some kind of "will an update change my WC"
> > command, add a --dry-run to "update", like make has, or something.
>
> You don't think a "status report" on your working copy should tell you
> what's out of date? CVS's status report certainly does, and I don't
> think that's a misfeature.
Just because CVS does, doesn't mean that we should. Joe's point about local
vs remote is good, and is kind of where I believe I was going in my post.
Just hadn't really got there :-)
> Taken from our spec:
That is rather disengenious. The spec does not say what we should be doing.
It is merely a document of thoughts from well over a year ago.
I think I'm in agreement with Joe, and would certainly appreciate an "svn
status" that is entirely local and only talks about what I've done in my WC.
If I want information about the *repository*, then I can use a different
command. If that is "svn update" or "svn repstat", then fine.
Let's go back to the use cases.
(1) what did I change?
(2) what is out of date?
In option 1, an output that says:
M foo/bar.c
A baz.h
M bleeb.c
Is exactly what I'm looking for. Adding --verbose will give the other
information.
If I want repository-based information, then I can run something else.
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
Re: update vs status, where should local mods be displayed?
Posted by Ben Collins-Sussman <su...@collab.net>.
Joe Orton <jo...@manyfish.co.uk> writes:
> I don't understand why people want to overload the "status" command with
> doing updatey things. "status" should show me the status of the WC - end
> of story. If you want some kind of "will an update change my WC"
> command, add a --dry-run to "update", like make has, or something.
You don't think a "status report" on your working copy should tell you
what's out of date? CVS's status report certainly does, and I don't
think that's a misfeature.
Taken from our spec:
Given this information, by talking to the repository, Subversion can
tell which of the following four states a file is in:
{Unchanged, and current.} [...]
{Locally changed, and current}. [...]
{Unchanged, and out-of-date}. [...]
{Locally changed, and out-of-date}. [...]
You really believe that 'svn status' should ignore this 2x2 matrix? I
mean, I've always assumed that to ask about the 'status' of a file
means to get one of the four answers above. I'd be really shocked if
we decided to change this definition of "status".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update vs status, where should local mods be displayed?
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Thu, Sep 13, 2001 at 01:25:06PM -0700, Mo DeJong wrote:
> % svn status
> N ./ac-helpers/install.sh
> M ./autogen.sh
> M ./build.conf
> A ./buildcheck.sh
Hoorah - this is pretty close to how my opinion of how "svn status"
should work. SVN currently has unreadable status output as well as CVS!
(until you read the docs and find -M)
Note that by eradicating that annoying and useless "remote repos
revision" field, you also eradicate the need to go to the server, so
this is an entirely local thing. Which is IMO how it should be. And you
can get rid of lots of the annoying whitespace too.
I don't understand why people want to overload the "status" command with
doing updatey things. "status" should show me the status of the WC - end
of story. If you want some kind of "will an update change my WC"
command, add a --dry-run to "update", like make has, or something.
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update vs status, where should local mods be displayed?
Posted by Philip Martin <ph...@ntlworld.com>.
[Oops, forgot to send to the list...]
Ben Collins-Sussman <su...@collab.net> writes:
> Instead, I was thinking of something like:
>
> % svn status
> Repository Revision: 96
> _ 95 ( * ) ./ac-helpers/install.sh
> _ 95 ( ) ./ac-helpers/svn-apache.m4
> _ 95 ( ) ./ac-helpers/svn-macros.m4
> M 95 ( ) ./autogen.sh
> M 95 ( ) ./build.conf
> A 0 ( ) ./buildcheck.sh
I don't think moving the repository version moving to a separate line
is a good idea. It makes the remaining lines less useful, they don't
have all the information. Consider, as an example, usage like
% svn status | grep \\.h$
(or Mo's first post in this thread). Scripts that process svn status
output will also find this form less useful.
A file can have been modified in both the local directory and the
repository since the local version was last updated. There are
*three* version numbers that are of interest: the version in the local
directory, the last version with a change in the repository, and the
most recent version in the repository. I think I would want to see
all three version numbers explicitly in every line, certainly the
first two. Blank space instead of a number is not a good idea, it
makes separation into fields harder.
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: update vs status, where should local mods be displayed?
Posted by Frohwalt Egerer <ma...@frohwalt.de>.
> -----Original Message-----
> From: Ben Collins-Sussman [mailto:sussman@collab.net]
> Sent: Donnerstag, 13. September 2001 23:55
> To: Philip Martin; SVN Dev List
> Subject: Re: update vs status, where should local mods be displayed?
[...]
> _ 95 [ *98] ( 99) ./ac-helpers/svn-macros.m4
> M 95 [ 95] ( 99) ./autogen.sh
[...]
> The first column is the working revision.
>
> The second column, in brackets, is the last revision in which the file
> changed. The asterisk is put there whenever this value is greater
> than the working revision -- pointing out that it needs to be updated.
>
> The third column, in parens, is the head revision, a constant value.
>
> Thoughts?
Isn't this a bit hard to grok for new or casual users? Figuring out what
these numbers mean does imply sleeping with the SVN manual under you pillow
at night. Maybe something easier would be appropriate, unless somebody
adds --verbose. *Then* the user knows, he will be getting lots of info.
Anoter interesting thing might be optionally genereating stuff in a form
that can easily be parsed. (CSV with fixed width fields, XML or whatever
...)
Frohwalt Egerer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update vs status, where should local mods be displayed?
Posted by Ben Collins-Sussman <su...@collab.net>.
[pushing this back to the dev list]
Philip Martin <ph...@ntlworld.com> writes:
> Ben Collins-Sussman <su...@collab.net> writes:
>
> > Instead, I was thinking of something like:
> >
> > % svn status
> > Repository Revision: 96
> > _ 95 ( * ) ./ac-helpers/install.sh
> > _ 95 ( ) ./ac-helpers/svn-apache.m4
> > _ 95 ( ) ./ac-helpers/svn-macros.m4
> > M 95 ( ) ./autogen.sh
> > M 95 ( ) ./build.conf
> > A 0 ( ) ./buildcheck.sh
>
> I don't think moving the repository version moving to a separate line
> is a good idea. It makes the remaining lines less useful, they don't
> have all the information. Consider, as an example, usage like
>
> % svn status | grep \\.h$
>
> (or Mo's first post in this thread). Scripts that process svn status
> output will also find this form less useful.
Very good point. Hmmm.
> A file can have been modified in both the local directory and the
> repository since the local version was last updated. There are
> *three* version numbers that are of interest: the version in the local
> directory, the last version with a change in the repository, and the
> most recent version in the repository. I think I would want to see
> all three version numbers explicitly in every line, certainly the
> first two. Blank space instead of a number is not a good idea, it
> makes separation into fields harder.
Yes, there are three numbers of interest; but the third number is a
constant. It irks me to always fill a whole column with the same
constant. But as you said, maybe it's worth the parsing benefit.
Maybe something like
% svn status --verbose
_ 95 [ 72] ( 99) ./ac-helpers/install.sh
_ 95 [ 90] ( 99) ./ac-helpers/svn-apache.m4
_ 95 [ *98] ( 99) ./ac-helpers/svn-macros.m4
M 95 [ 95] ( 99) ./autogen.sh
M 95 [ 16] ( 99) ./build.conf
A 0 [ 0] ( 99) ./buildcheck.sh
The first column is the working revision.
The second column, in brackets, is the last revision in which the file
changed. The asterisk is put there whenever this value is greater
than the working revision -- pointing out that it needs to be updated.
The third column, in parens, is the head revision, a constant value.
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update vs status, where should local mods be displayed?
Posted by Ben Collins-Sussman <su...@collab.net>.
Mo DeJong <su...@bayarea.net> writes:
> % svn status
> _ 95 ( 95) ./ac-helpers/install.sh
> _ 95 ( 95) ./ac-helpers/svn-apache.m4
> _ 95 ( 95) ./ac-helpers/svn-macros.m4
> M 95 ( 95) ./autogen.sh
> M 95 ( 95) ./build.conf
> A 0 ( 95) ./buildcheck.sh
By the way, Mo, thanks for being so lucid and reasonable in your
discussions. :-)
> What I am suggesting is that we do this "compare rev numbers"
> check for the user and only present them with interesting status info
> like when a revision transition for a file actually does something.
> For example, we could use 'N' to indicate that the local file needs
> a patch from the server.
>
> % svn status
> N 95 ( 96) ./ac-helpers/install.sh
> _ 95 ( 96) ./ac-helpers/svn-apache.m4
> _ 95 ( 96) ./ac-helpers/svn-macros.m4
> M 95 ( 96) ./autogen.sh
> M 95 ( 96) ./build.conf
> A 0 ( 96) ./buildcheck.sh
This is similar to what we're planning to do. We're well aware that
comparing revision numbers is insufficient for checking
up-to-dateness. I think we're in agreement here... it's just a matter
of how to paint the bikeshed.
I think it's a good idea to continue the semantic tradition of only
displaying local-mod symbols in that first column. I don't like the
idea of mixing a 'needs an update' flag in there.
Instead, I was thinking of something like:
% svn status
Repository Revision: 96
_ 95 ( * ) ./ac-helpers/install.sh
_ 95 ( ) ./ac-helpers/svn-apache.m4
_ 95 ( ) ./ac-helpers/svn-macros.m4
M 95 ( ) ./autogen.sh
M 95 ( ) ./build.conf
A 0 ( ) ./buildcheck.sh
Notice that the head revision only needs to be printed once. And the
parenthesis column can now be used to display 'update' related flags,
while the first column shows 'commit' related flags. In the example
above, an asterisk (*) means install.sh needs an update.
We could make a fancier update flag, though:
% svn status
Repository Revision: 99
_ 95 ( 97) ./ac-helpers/install.sh
_ 95 ( ) ./ac-helpers/svn-apache.m4
_ 95 ( ) ./ac-helpers/svn-macros.m4
M 95 ( ) ./autogen.sh
M 95 ( ) ./build.conf
A 0 ( ) ./buildcheck.sh
Notice the head revision is 99, and the '97' means that install.sh was
modified in revision 97.
> % svn status
> N ./ac-helpers/install.sh
> M ./autogen.sh
> M ./build.conf
> A ./buildcheck.sh
This example of yours presents -two- new ideas:
* only display files that have interesting commit or update flags
* don't show any revision numbers at all
First : I could definitely go for the first idea. When I run plain
old 'svn status', I think it's a fine idea to print fewer lines
overall. Why show the uninteresting files? A verbose option can show
everything, and give us a clear sense of exactly what's under version
control. +1 from me.
Second : I think the local revision numbers should be displayed no
matter what. Why? Because I'd like to (possibly) use them as a sort
of update-flag, as in my earlier example. Also, (and more
importantly), I think it's bad UI design to change the "look" of a
status line in different situations. The brain habituates its parsing
of a single line of output; we should reward that habituation by
keeping the line format consistent, whether we're seeing a condensed
or verbose status list.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update vs status, where should local mods be displayed?
Posted by Mo DeJong <su...@bayarea.net>.
On 13 Sep 2001 14:10:22 -0500
Ben Collins-Sussman <su...@collab.net> wrote:
> Mo DeJong <su...@bayarea.net> writes:
>
> > Let me ask this. What is the benefit of spewing out a status
> > line for each and every file in the repo by default? What
> > question does the end user seek to answer by looking at
> > all this status output? Is there an end user question that
> > can't be answered by the output if -M style output was
> > the default?
>
> There are two common use-cases for 'svn status', I believe.
>
> 1. To see local mods
>
> The user wants to know exactly what to commit, or what would be
> committed. No other clutter.
>
> 2. To examine 'up-to-dateness'.
>
> The user wants to know which files are out-of-date. This means seeing
> local revision numbers on files, but *mostly* seeing out-of-date
> flags. The user can then predict exactly what will be patched when
> 'svn up' is run.
Both of these use cases are perfectly reasonable. While I certainly think
that case 1 is going to be much more common than case 2, I don't think
we need to sacrifice 2 to get 1. I just think that the current svn status
output is not the best way to satisfy case 2. Let me explain what I mean
with an example.
For the sake of this example, pretend I have a small repo with only
6 files (the problem would get worse with more files in the repo).
% svn status
_ 95 ( 95) ./ac-helpers/install.sh
_ 95 ( 95) ./ac-helpers/svn-apache.m4
_ 95 ( 95) ./ac-helpers/svn-macros.m4
M 95 ( 95) ./autogen.sh
M 95 ( 95) ./build.conf
A 0 ( 95) ./buildcheck.sh
This status output certainly helps me see local mods, so we are covered there.
Now I want to examine up-to-dateness, what do I do? I would start with:
"_ 95 ( 95) ./ac-helpers/install.sh"
My local version number of 95 matches the server rev of 95 so
I would conclude that this file is up to date with respect to the
server. I would then rinse and repeat this process for each and
every line in the status output. Now lets say someone checked
in a change to install.sh, the revision on the server would be
upped and I would see that new server rev number in the
output of each and every line. The end user would not have
any way to know that it was install.sh that had been updated.
What I am suggesting is that we do this "compare rev numbers"
check for the user and only present them with interesting status info
like when a revision transition for a file actually does something.
For example, we could use 'N' to indicate that the local file needs
a patch from the server.
% svn status
N 95 ( 96) ./ac-helpers/install.sh
_ 95 ( 96) ./ac-helpers/svn-apache.m4
_ 95 ( 96) ./ac-helpers/svn-macros.m4
M 95 ( 96) ./autogen.sh
M 95 ( 96) ./build.conf
A 0 ( 96) ./buildcheck.sh
That does a much better job of telling the user what is going to be
pulled down during the next call to `svn update`. If that is the case,
there really is no reason to show files that are not modified or in
need of an update at all. By the same token, we don't even need
to display the actual revision number. We could drastically
simplify the output and get rid of the need for the -M flag
by only displaying those files that were changed locally
or on the server.
% svn status
N ./ac-helpers/install.sh
M ./autogen.sh
M ./build.conf
A ./buildcheck.sh
Of course, some folks might really want to see the rev numbers.
Perhaps showing the rev numbers in this case would be a better
use for the --verbose flag to the status subcommand. After all,
do we really get any benefit from printing a status line for
a file that is not changed locally or on the server?
...
> > > 2. 'svn status' can show only the current directory, or it can
> > > display a long recursive list.
> > >
> > > To be decided: what behavior should be the "default", and which
> > > should require a switch?
> > >
> > > I personally would like to make nonrecursive the default, which is
> > > not the status quo. I haven't heard anyone defending the status
> > > quo yet. (?)
> >
> > I could not disagree more strongly. Why make this one command
> > non-recursive by default when update is not? Users are supposed
> > to use status instead of update, right?
>
> You're right, I retract. {commit, update, checkout, diff} are all
> recursive by default. Let's leave status recursive too.
Whew.
> > P.S.
> > Here is a quick snip from my local copy of svn_cl__print_status_list.
> > It implements the (M,A,D,R) thing Ben suggested above.
>
> I already committed something similar, revision 100. 'svn st -M'
> now works the way you suggested.
Great, thanks much.
Mo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update vs status, where should local mods be displayed?
Posted by Ben Collins-Sussman <su...@collab.net>.
Mo DeJong <su...@bayarea.net> writes:
> Let me ask this. What is the benefit of spewing out a status
> line for each and every file in the repo by default? What
> question does the end user seek to answer by looking at
> all this status output? Is there an end user question that
> can't be answered by the output if -M style output was
> the default?
There are two common use-cases for 'svn status', I believe.
1. To see local mods
The user wants to know exactly what to commit, or what would be
committed. No other clutter.
2. To examine 'up-to-dateness'.
The user wants to know which files are out-of-date. This means seeing
local revision numbers on files, but *mostly* seeing out-of-date
flags. The user can then predict exactly what will be patched when
'svn up' is run.
The heart of the this debate is: "which use case is more common?"
Whichever is more common -- that should be the default.
On this issue, my own experience may be skewed; I spend every day of
life playing with Subversion, running dozens of hand-tests on test
working copies. I use 'svn st' and have come to depend on it more
often than I run 'ls'. So I value the 2nd use case more. However,
I'm guessing that a typical user (not developer) more often needs the
first use-case. That is, users more often want to predict (or plan)
commits than predict updates.
So, I'm willing to change the default to #1 if that's the consensus.
I wonder what others think.
> > 2. 'svn status' can show only the current directory, or it can
> > display a long recursive list.
> >
> > To be decided: what behavior should be the "default", and which
> > should require a switch?
> >
> > I personally would like to make nonrecursive the default, which is
> > not the status quo. I haven't heard anyone defending the status
> > quo yet. (?)
>
> I could not disagree more strongly. Why make this one command
> non-recursive by default when update is not? Users are supposed
> to use status instead of update, right?
You're right, I retract. {commit, update, checkout, diff} are all
recursive by default. Let's leave status recursive too.
> P.S.
> Here is a quick snip from my local copy of svn_cl__print_status_list.
> It implements the (M,A,D,R) thing Ben suggested above.
I already committed something similar, revision 100. 'svn st -M'
now works the way you suggested.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update vs status, where should local mods be displayed?
Posted by Mo DeJong <su...@bayarea.net>.
On 13 Sep 2001 12:33:47 -0500
Ben Collins-Sussman <su...@collab.net> wrote:
> Sander, I'm glad you agree with everything I said. :-)
>
> But, let me summarize the proposed changes on the table:
>
> 1. 'svn status' is capable of showing local mods (M, A, D, R) only,
> and it's also capable of showing local mods plus everything else
> (for seeing mixed revisions in a directory.)
>
> To be decided: what behavior should be the "default", and which
> should require a switch?
>
> It sounds like Mo wants the first behavior to be the default. I
> personally like the second behavior to be the default, which is
> what we have now.
The current `svn status` behavior could be activated when the --verbose
switch is passed. By default, the suggested (M,A,D,R) with -M
behavior should be used (and we could remove -M, simple is good).
The functionality the -M provides is so useful that it should
be the default. This would provide a much more "cvs update"
like behavior and would avoid overloading users with a line
of output for each and every file in the repository. Sure, we
could just punt and tell users they can add "status -M" to
a ~/.svnrc file. Thing is, bad defaults is one of the things that
bothers me most about CVS.
Let me ask this. What is the benefit of spewing out a status
line for each and every file in the repo by default? What
question does the end user seek to answer by looking at
all this status output? Is there an end user question that
can't be answered by the output if -M style output was
the default?
> 2. 'svn status' can show only the current directory, or it can
> display a long recursive list.
>
> To be decided: what behavior should be the "default", and which
> should require a switch?
>
> I personally would like to make nonrecursive the default, which is
> not the status quo. I haven't heard anyone defending the status
> quo yet. (?)
I could not disagree more strongly. Why make this one command
non-recursive by default when update is not? Users are supposed
to use status instead of update, right?
> I think an important use-case of 'svn status' is to get an overall
> snapshot of your directory -- seeing exactly how "mixed" your working
> copy revisions are.
Why? I can't imaging end users will really care that much about how
mixed files revision numbers are. That does not really tell me anything
other than the fact that someone has checked something into the repo
since I last did an update. Users would care much more about whether
or not they needed to do an update to pull down changes for a specific
file before a commit or about local changes they have made. I think we
need to be careful to avoid setting defaults that are good for developers
but don't really help end users.
cheers
Mo
P.S.
Here is a quick snip from my local copy of svn_cl__print_status_list.
It implements the (M,A,D,R) thing Ben suggested above.
if ((status->text_status == svn_wc_status_added)
|| (status->prop_status == svn_wc_status_added)
|| (status->text_status == svn_wc_status_conflicted)
|| (status->prop_status == svn_wc_status_conflicted)
|| (status->text_status == svn_wc_status_deleted)
|| (status->prop_status == svn_wc_status_deleted)
|| (status->text_status == svn_wc_status_modified)
|| (status->prop_status == svn_wc_status_modified)
|| (status->text_status == svn_wc_status_merged)
|| (status->prop_status == svn_wc_status_merged)
|| (status->text_status == svn_wc_status_replaced)
|| (status->prop_status == svn_wc_status_replaced))
svn_cl__print_status (svn_stringbuf_create (path, pool), status);
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update vs status, where should local mods be displayed?
Posted by Ben Collins-Sussman <su...@collab.net>.
Sander, I'm glad you agree with everything I said. :-)
But, let me summarize the proposed changes on the table:
1. 'svn status' is capable of showing local mods (M, A, D, R) only,
and it's also capable of showing local mods plus everything else
(for seeing mixed revisions in a directory.)
To be decided: what behavior should be the "default", and which
should require a switch?
It sounds like Mo wants the first behavior to be the default. I
personally like the second behavior to be the default, which is
what we have now.
2. 'svn status' can show only the current directory, or it can
display a long recursive list.
To be decided: what behavior should be the "default", and which
should require a switch?
I personally would like to make nonrecursive the default, which is
not the status quo. I haven't heard anyone defending the status
quo yet. (?)
3. 'svn status' needs to show if each file in the head server
revision has -actually- changed. This is a big coding task (#385).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: update vs status, where should local mods be displayed?
Posted by Sander Striker <st...@apache.org>.
> -----Original Message-----
> From: Ben Collins-Sussman [mailto:sussman@collab.net]
> Sent: 13 September 2001 18:54
> Mo DeJong <su...@bayarea.net> writes:
>
>> (Possible output)
>>
>> % svn update
>> % svn -M status
>> M 95 ( 95) ./configure.in
>> M 95 ( 95) ./gen-make.py
>> A 0 ( 95) ./buildcheck.sh
>
> I agree, right now "-M" is only printing (M)odified and (C)onflicted
> files. But I believe that scheduling an object for (A)ddition,
> (D)eletion or (R)eplacement should show up with this flag as well.
> They're all local modifications in their own way. I can make this
> change if others agree.
+1 :)
>> For example, here is a quick snip from the output of status
>> on my machine:
>>
>> _ 95 ( 95) ./ac-helpers/install.sh
>> _ 95 ( 95) ./ac-helpers/svn-apache.m4
>> _ 95 ( 95) ./ac-helpers/svn-macros.m4
>> M 95 ( 95) ./autogen.sh
>> M 95 ( 95) ./build.conf
>> A 0 ( 95) ./buildcheck.sh
>>
>>
>> What information does the first three lines really provide?
>> Can't we communicate that the install.sh, svn-apache.m4,
>> and svn-macros.m4 files are up to date and have not been
>> changed by not printing a line of output for them?
>
> I think an important use-case of 'svn status' is to get an overall
> snapshot of your directory -- seeing exactly how "mixed" your working
> copy revisions are.
>
> However -- you do raise an issue that has been on the back-burner for
> a while. Right now, our 'status' command does *not* match all the
> functionality of CVS's 'status' command (other than being easier to
> read). Specifically, our status command is unable to tell the user if
> a particular file actually out-of-date content-wise. Just because you
> have version 90 of foo.c, and the repository is at 95, doesn't mean
> that foo.c has changed contents!
>
> Issue #385 talks about this. Our plan is to possibly print the
> repository revision on its own first line, and use the column in
> parenthesis to show whether the file is *actually* different on the
> server. This could be done by placing an asterisk in the parens, or
> it could be much fancier -- like displaying the revision number in
> which this file last changed.
Oo, I like that.
> > This can be quite a problem even for a small repo
> > with hundreds of entries. Sifting through thousands
> > of entries worth of output would be even worse.
>
> Different issue. 'svn status -n' shows only the CWD
> (--nonrecursive). I've long thought that -n should be the implied
> *default*, because people rarely want to see hundreds of lines of
> output all at once. (For the same reason people run 'ls', and rarely
> run 'ls -R'.) I'd love to make that change.
+1 on that one too.
>> What I am suggesting is that the default output of the
>> status command should not display every file. Instead
>> the default should display info for locally modified
>> file, locally added files, and locally deleted files
>> (I assume modified props would also apply here). We
>> could add a `svn status -v` option to print out the
>> really verbose output that is currently displayed.
>
> I don't like this. Like I said, my own personal habits are to use
> 'svn st' much like I use 'ls'. "Show me the state of everything in my
> CWD." I want to know not only about local mods, but mixed-revisions
> as well. If I want to know what to commit (or what will happen when I
> commit), then I run 'svn st -M'.
I'm with Ben on this one. The above change would make
svn status equivalent to svn status -M.
svn status _should_ show every file, since you want to know the
status of every file, not just the ones modified/added/etc.
>> On a related but separate note, should the `svn update`
>> command do something similar? It currently ignores
>> local mods, adds, and deletes.
>
> I'm not sure why you want this behavior, other than "it's what I'm
> used to with CVS". They're logically different ideas. When updating
> my working copy, why should local mods be printed? Updates should
> tell me what's being patched, *not* give me an overview of my working
> copy status. That's what 'svn status' is for.
I agree.
> Many CVS users have developed a habit of running 'svn up' *soley* for
> the purpose of seeing their local mods displayed conveniently. This
> habit exists because 1) CVS's status command produces hideous output,
> and 2) because 'cvs up' sloppily mixes two concepts. By deliberately
> separating the concepts in Subversion, and by producing simple status
> output, we hope to break this habit.
Which is really a good thing.
> Todo: we really need folks to document these new or not-new behaviors
> -- either by adding to doc/user/manual/, or perhaps somebody could
> volunteer to write a short, consise "Subversion for Former CVS Users"
> document which explains all the differences. That document would be
> invaluable.
Indeed.
Sander
PS. Ofcourse my votes are my personal opinion and non-binding.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update vs status, where should local mods be displayed?
Posted by Ben Collins-Sussman <su...@collab.net>.
Mo DeJong <su...@bayarea.net> writes:
> (Possible output)
>
> % svn update
> % svn -M status
> M 95 ( 95) ./configure.in
> M 95 ( 95) ./gen-make.py
> A 0 ( 95) ./buildcheck.sh
I agree, right now "-M" is only printing (M)odified and (C)onflicted
files. But I believe that scheduling an object for (A)ddition,
(D)eletion or (R)eplacement should show up with this flag as well.
They're all local modifications in their own way. I can make this
change if others agree.
> For example, here is a quick snip from the output of status
> on my machine:
>
> _ 95 ( 95) ./ac-helpers/install.sh
> _ 95 ( 95) ./ac-helpers/svn-apache.m4
> _ 95 ( 95) ./ac-helpers/svn-macros.m4
> M 95 ( 95) ./autogen.sh
> M 95 ( 95) ./build.conf
> A 0 ( 95) ./buildcheck.sh
>
>
> What information does the first three lines really provide?
> Can't we communicate that the install.sh, svn-apache.m4,
> and svn-macros.m4 files are up to date and have not been
> changed by not printing a line of output for them?
I think an important use-case of 'svn status' is to get an overall
snapshot of your directory -- seeing exactly how "mixed" your working
copy revisions are.
However -- you do raise an issue that has been on the back-burner for
a while. Right now, our 'status' command does *not* match all the
functionality of CVS's 'status' command (other than being easier to
read). Specifically, our status command is unable to tell the user if
a particular file actually out-of-date content-wise. Just because you
have version 90 of foo.c, and the repository is at 95, doesn't mean
that foo.c has changed contents!
Issue #385 talks about this. Our plan is to possibly print the
repository revision on its own first line, and use the column in
parenthesis to show whether the file is *actually* different on the
server. This could be done by placing an asterisk in the parens, or
it could be much fancier -- like displaying the revision number in
which this file last changed.
> This can be quite a problem even for a small repo
> with hundreds of entries. Sifting through thousands
> of entries worth of output would be even worse.
Different issue. 'svn status -n' shows only the CWD
(--nonrecursive). I've long thought that -n should be the implied
*default*, because people rarely want to see hundreds of lines of
output all at once. (For the same reason people run 'ls', and rarely
run 'ls -R'.) I'd love to make that change.
> What I am suggesting is that the default output of the
> status command should not display every file. Instead
> the default should display info for locally modified
> file, locally added files, and locally deleted files
> (I assume modified props would also apply here). We
> could add a `svn status -v` option to print out the
> really verbose output that is currently displayed.
I don't like this. Like I said, my own personal habits are to use
'svn st' much like I use 'ls'. "Show me the state of everything in my
CWD." I want to know not only about local mods, but mixed-revisions
as well. If I want to know what to commit (or what will happen when I
commit), then I run 'svn st -M'.
> On a related but separate note, should the `svn update`
> command do something similar? It currently ignores
> local mods, adds, and deletes.
I'm not sure why you want this behavior, other than "it's what I'm
used to with CVS". They're logically different ideas. When updating
my working copy, why should local mods be printed? Updates should
tell me what's being patched, *not* give me an overview of my working
copy status. That's what 'svn status' is for.
Many CVS users have developed a habit of running 'svn up' *soley* for
the purpose of seeing their local mods displayed conveniently. This
habit exists because 1) CVS's status command produces hideous output,
and 2) because 'svn up' sloppily mixes two concepts. By deliberately
separating the concepts in Subversion, and by producing simple status
output, we hope to break this habit.
Todo: we really need folks to document these new or not-new behaviors
-- either by adding to doc/user/manual/, or perhaps somebody could
volunteer to write a short, consise "Subversion for Former CVS Users"
document which explains all the differences. That document would be
invaluable.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org