Ben, I've been thinking more about this and while I'm just a peon (no
voting and as yet no code contrib...), I do have a couple of issues with
this proposal:
First, what is the intention/scenario here? It seems to me we have two
possibilities: (a) changelists as a mnemonic device, to assist in
remembering what needs to be checked-in, and (b) changelists as an
enforcement device, to add some kind of policy mechanism to help users
in "doing the right thing".
I assert that (a) can be handled comfortably with shell scripts, or (at
most), the addition of a switch to the SVN client to read file list
files (aka response files), i.e.:
svn commit @changelist.txt -m "Commit log message"
Where "changelist.txt" presumably contains a file list, delimited in
some convenient manner.
If the intent is (b), I'm not clear what the goal is? For example, is
the intent to ensure that commit are atomic with regard to source tree
coherency? If that's the case, we would need behaviors that include
things like (a) disallowing checkins of individual files if they are on
a changelist and (b) disallowing a file on more than one changelist
(auto-merge). At that point a changelist is sounding more like a
work-item and is more related to overall development workflow?
Now, I think (b) might have value, but my reading of your proposal is
that this is not what you intended. Comments?
--Tim
Ben Collins-Sussman wrote:
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 19 03:43:41 2006