On Wed, 2011-08-24 at 15:10 +0300, Daniel Shahaf wrote: > Julian Foad wrote on Wed, Aug 24, 2011 at 11:13:09 +0100: > > > > C. Michael Pilato wrote: > > > >> So back to what I would consider the primary deliverable of interest > > > >> here: > > > >> avoiding one's own accidental commits. I'm leaning toward [...] A > > > >> special changelist honored by our libsvn_client code which does what > > > >> we're > > > >> talking about here, shows up in 'svn status' like the others do, > > > >> requires > > > >> very little additional infrastructure, for which state changes are not > > > >> versioned operations (such as they would be with the commits of the > > > >> addition > > > >> and removal of an svn:hold property), etc. > > > > I like the sound of this, too, as the local-only part of the solution. > > See below for the centralized part of the solution. > > > > The set of changelists to use is already passed into the libsvn_client > > API from the client. Pretty much all we need is a way to specify sets > > of changelists more flexibly. For the main functionality, the 'commit' > > subcommand would specify "select everything except changelist > > 'svn:ignore-on-commit'" unless overridden. That would make the file be > > Does this require negative changelists? Currently changelists are > 'select only members of this changelist', but you're proposing 'select except > members of this changelist'.
Yes. If that sounds like a non-trivial extension of the changelist semantics, it's not. Imagine we have an API to retrieve a list of all the changelist names and a pseudo-changelist indicator to denote "files that are not in any changelist". Then we could simply map that request into a select-multiple-changelists request. So semantically it's not new. It does need an API change of one kind or another. - Julian
