[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: proposal: changelist feature

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2006-04-20 15:16:19 CEST

It's interesting where this thread has gone! I originally proposed a
tiny bookkeeping feature, based on the fact that I (and others) have
become addicted to said bookkeeping when using perforce every day. I
was initially worried that the discussion would start heading down a
path of "stop crawling the working copy, store changelists in
~/.subversion/", which is a very perforce-like thing to do.

Instead, however, people have been wandering down two other paths I'd
didn't anticipate.

  * Some folks have started with my idea, and inferred some sort of a
structured SCM methodology being imposed on users. This was never my
intent. Changelists aren't things to be "enforced" by the software...
I really only meant them to be some convenient bookkeeping on the
side. (Yes, it could be done by users keeping changelists in a bunch
of text-files, but it wouldn't be as convenient, and 'svn status'
wouldn't be able to show them, which is the critical bit for me.)

  * Other folks have brought up the idea (in this thread, and in IRC)
of "well, heck, what people _really_ want are enhanced commit
abilities". Some have suggested a 'shelving' feature, which allows
one to push a patch-in-progress to an automatically-generated
mini-branch in the repository. A few others have suggested "offline
commits", as seen in distributed SCMs, whereby the working copy
becomes "deeper", able to hold more than one tree at a time.

I definitely have no interest in the first bullet. I feel like the
ideas in the second bullet are interesting, but also a bit out of
scope for my ambitions at the moment. If anything, while my proposal
might 'inspire' those ideas, I feel like they're orthogonal projects.

Here's my plea: let me make a feature branch, and code this really
simple bookkeeping feature. Once you've all played with it and
discovered how (unexpectedly) useful it is, we can go back and visit
some of these other more complex feature proposals in new mail
threads...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 20 15:17:28 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.