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

Re: dump svn:hold, long live file externals?? (and discussing recursive hold) -- was: bring on your concerns about svn:hold, please

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Wed, 24 Aug 2011 13:23:53 +0100

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
Received on 2011-08-24 14:24:34 CEST

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