Some questions/issues:
1. As another has asked, can a file be in more than one changelist? If
so, what are the implications for checkin?
2. Presumably some means would be needed to edit changelists, including
removing files from lists and/or deleting them?
3. Presumably, a changelist vanishes when it's checked-in? But if we
allow a file in >1 changelist, what happens when the changelist is
pre-empted by other checkins (e.g. list1 contains files A and B, list2
contains B. Checkin list1, list2 is now an empty set???).
4. If this gets added, someone is going to want a way to tag (in the
respository) the name of the changelist against the repo revision. Then
someone will want to search on these. Then someone will notice that this
is a back-door to revision labels, which everyone here seems to
hate...... :(
I also have a more general workflow question: what is the problem being
solved here? Are we looking at a scenario where several (possibly
overlapping) changes are being worked on simultaneously? When I do this,
I always handle it by creating distinct working copies, and then doing
multiple checkins with merges as necessary. This also has the advantage
of making each checkin atomic (with respect to features), even if the
changes incolve overlapping files. The distinct WCs then act as, in
effect, changelists all by themselves. Perforce cannot do this since it
ties the WC and the server more closely than SVN.
--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 Tue Apr 18 03:44:01 2006