Hi folks, it's been a while since I worked on subversion coding
project. This is a proposal for a new client-side feature I'd like to
work on. (For svn 1.5, obviously, not 1.4).
It's vaguely based on a similar feature in perforce, and it's
something a few of us have gotten used to since working at Google -- a
nice convenience.
In a nutshell, it's a way to attach temporary names to groups of
edited files in a working copy. If you've ever been working on
several different patches or tasks at the same time, it's easy to get
them confused. Perforce allows you to give a name to a set of files,
called a 'changelist'.
* 'svn status' would not only show local files as modified or
scheduled for addition/deletion, but also which changelist each
path belongs to. (Assuming you've bothered to assign changed
paths to changelists.)
* Anytime one might normally use a list of local paths on the
commandline, one could use a changelist name instead. For
example, one could revert, diff, or commit a changelist name.
* The only new UI-syntax we'd need is
- the ability to associate (or deassociate) a local path with a
changelist name
- a new commandline option to specify a changelist name.
Here's an imaginary demo of what this feature might be like.
---------------------------------
$ cd wc
$ echo "new text" >> foo.c
$ touch bar.c; svn add bar.c
A bar.c
$ svn st
M foo.c
A bar.c
$ svn changelist issue-2899 foo.c bar.c
foo.c is is now part of changelist 'issue-2899'.
bar.c is is now part of changelist 'issue-2899'.
$ svn st
Changelist 'issue-2899':
M foo.c
A bar.c
$ echo "blah" >> baz.c
$ svn st
M baz.c
Changelist 'issue-2899':
M foo.c
A bar.c
$ svn changelist feature-baz baz.c
baz.c is is now part of changelist 'issue-2899'.
$ svn st
Changelist 'feature-baz':
M baz.c
Changelist 'issue-2899':
M foo.c
A bar.c
$ svn diff --changelist issue-2899
(diffs for foo.c and bar.c are shown)
$ svn rm glorb.h
D glorb.h
$ svn changelist feature-baz glorb.c
svn: error: glorb.c isn't edited or scheduled.
$ svn changelist feature-baz glorb.h
glorb.h is is now part of changelist 'feature-baz'.
$ svn st
Changelist 'feature-baz':
M baz.c
D glorb.h
Changelist 'issue-2899':
4 M foo.c
A bar.c
$ svn changelist issue-2899 glorb.h
glorb.h is is now part of changelist 'issue-2899'.
$ svn st
Changelist 'feature-baz':
M baz.c
Changelist 'issue-2899':
M foo.c
A bar.c
D glorb.h
$ svn commit --changelist issue-2899
Adding bar.c
Sending foo.c
Deleting glorb.h
Transmitting file data..
Committed revision 23489.
-------------------------------
How this is different than perforce:
In perforce, the server tracks *every* working copy. In fact, working
copy files are read-only, and you need to tell the server you want to
edit them before they become read-write. Ergo, changelists are
entirely tracked by the server. On the one hand, this makes commands
like 'status' or 'commit' super-quick: instead of needing to crawl the
working copy for changes, a quick network request to the server
returns all the changed paths. On the other hand, this sort of thing
is only possible with a system designed for a LAN. Subversion is
WAN-based, so I'd never advocate that sort of design.
An initial super-simple implementation of such a feature could be
nothing more than attaching a changelist name as an 'entry-prop' in
.svn/entries, or something similar. Later on, if we wanted to get
fancy and try to make the svn client also be "super quick" and avoid
crawls, we *could* have the client track changelists in a central
registry, such as in ~/.subversion/. Of course, the tradeoff is that
it takes us one more step towards the idea of working copies being
non-divisible and non-portable. Not sure we want to open that
discussion. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 17 20:10:35 2006