Re: changelist feature -- keep it? tweak it? scrap it?

On 1/16/07, Ben Collins-Sussman <sussman@red-bean.com> wrote:
>
> Hm, those are very good points, Karl.
>
> I was originally going to reply that you and CMike were both sort of
> throwing shadows, giving fuzzy arguments that "in your gut" this
> implementation wouldn't lead us down the path we wanted. My reply
> would have been along the lines of quoting ghudson ("don't let the
> perfect become the enemy of the good").
>
> But you're right, using scattered entries files as a database is a
> pretty poor design. And yeah, it makes it hard to implement
> overlapping changesets. I probably wasn't noticing this problem
> because all of the subcommands that filter on the new label are doing
> recursive walks anyway... but there are many other uses for
> changelists, and a client application shouldn't *have* to do a
> recursive walk just to know who a changelist's members are. Yuck.
> That's really restrictive.
>
> So, I concede. I just wish that, you know, somebody had been paying
> attention to my commits all last May. A simple "don't do it that way"
> would have saved a lot of time and backtracking. :-) Back then, we
> spent a long while hashing out the use-cases and UI (in
> notes/changelist-design.txt), but no time discussing underlying
> implementation. Seems like the design file is still good, but the
> implementation is not.

I do not know if this will add to the conversation or not. But the subject
of other SVN clients has been brought up, so I think it might be relevant.

I just wanted to point out that Subclipse has had support for "Change Sets"
for a while now. It is rooted in an Eclipse feature that they provide for
CVS, but expose as a generic API for all "Team" providers. Eclipse contains
a common "Synchronize" view that you can use to update/commit from.
Basically a graphical version of svn status -u. I have posted links to a
screenshot before:

http://subclipse.tigris.org/images/sync-ss.png

Anyway, this view also contains UI to support change sets. We just had to
do the necessary work in Subclipse to drive the view and make it all work
correctly. Basically, you can group files into change sets, and write/save
the commit message associated with the change set. You can then commit when
you want to. There is also an "incoming" component to this, where the
changes that need to come in from the repository can be grouped by change
set, which is just the revision and log message for that revision in the
case of SVN. A file changed multiple times only shows in the latest
grouping. I do not want to get too off topic but there is another Eclipse
plugin called Mylar that adds another dimension to this and lets you work in
a task focused UI. This automatically creates change sets for the tasks you
are working on, and populates the change set with files as you change them
while a task is "active". It is very cool and lets you open/close entire
sets of editors by activating or deactivating a task you are working on.
All integrated with Bugzilla, IssueZilla etc...

I could put together something for my blog with more screen shots if it
would help.

Getting back on topic, we did not need any new or special API's to implement
this. I do not have any need or plans to move it over to the new feature in
SVN either, as the only benefit would be to move between clients. In this
case, that does not feel overly critical feature to have.

Obviously to support "hunks" would require API support, unless we were going
to really change our philosophy in Subclipse and manipulate the WC with our
own code.

I am not against this feature being added to the command line. I view the
CLI as a UI, and this is its implementation. The fact that the CLI has this
feature does not prevent Subclipse from having its own, and it gives is an
option to reuse it if that is the best way to do it.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/