Tim Hill wrote:
> 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.
> [snip]
I would say my description matches (a), but Ben's description does not
match (a) entirely. Implementing a changelist as a per-file Working Copy
(WC) property opens up the possibility of tracking major file changes
locally after the point the changelist property is applied. I.e. "svn mv
file" and "svn rename file" would not affect the changelist status of
the file. My description, and (a), where a list is maintained completely
outside the Working Copy (WC) system, makes tracking across moves and
renames non-trivial, and leaves more changelist updating tasks to the
user. Of course, (a) makes other features easier, such as including
items in a changelist that haven't even been modified/added yet, and
maintaining the same changelists across commits and WCs.
About (b), I would say user control of that form is a losing game.
Changelists should be about making it easier for users to commit, not
harder. Your multi-WC system sounds like a better way of going around
the "different patches intended, same file committed" problem mentioned
earlier.
When I was suggesting a "user-controlled branch commit now, merge to
trunk later" workflow, I was just saying it is similar to your multi-WC
workflow. Think (user-branch = WC-copy), just one is server-store and
the other is local-store. The big difference is that
branch-commit/trunk-merge cycles would benefit from pervasive
changelists in a way that the multi-WC workflow would not. Users could
re-use the same changelists (as used in previous branch commits) during
the trunk-merge cycle. A multi-WC merge cycle is implicit in the WC
commit order, and wouldn't have a lot of Changelist cross-over potential.
--Jared
> 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
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 19 06:46:46 2006