[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: Daniel Shahaf <danielsh_at_elego.de>
Date: Wed, 24 Aug 2011 15:31:13 +0300

Julian Foad wrote on Wed, Aug 24, 2011 at 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.
>

Fair enough.

For simplicity, we can retain the status quo where no changelists are
allowed on directories? Otherwise we'd have to decide how a negative
changelist behaves when applied to a directory.

(It could mean changelists are to be coupled with a depth value; but
let's not open that can of worms unless we have to.)

> - Julian
>
>
Received on 2011-08-24 14:32:08 CEST

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.