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

Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Wed, 24 Aug 2011 23:36:27 +0300

Neels J Hofmeyr wrote on Wed, Aug 24, 2011 at 22:04:11 +0200:
> On 08/24/2011 04:01 PM, Daniel Shahaf wrote:
> > Neels J Hofmeyr wrote on Wed, Aug 24, 2011 at 15:32:20 +0200:
> >> Changelists have been *designed* in the flipped-over wrong-way-round: they
> >> *include*, not exclude selected items. We'd have to implement this against
> >> its basic design. (Like using switch for externals, remember?)
> >
> > Changelists were designed to group files. What's fundamentally flawed in
> >
> > % svn cl foo A/mu ./iota
> > % svn commit --depth=empty A/mu ./iota --except-cl=foo
> Usually the code goes like "if there is a changelist, act on the node only
> when it is part of the changelist." ...well, it's just what I remember
> faintly, admittedly. Is that true?

My recollection is that 'svn $subcommand foo --changelist bar' applies
to one of:

- the subset of descendants of that are in changelist 'bar';
- both to foo and to members of 'bar'

where some subcommands behave differently than others.

> If it isn't, there's nothing wrong with your command at all. In fact that
> would be quite nice.
> But from the ignore-on-commit perspective, you still need to remember to
> supply it at commit time.
> You'd need to make the changelist always secretly self-acting, and thus the
> changelist must have a special name, as Hyrum kindly pointed out :)
> If I can instead create a simple property to achieve the same, I'm happier.

We could decide that the special changelist is always applied, unless
a node has been explicitly named as a commit target. It wouldn't even
require a revision of the API signature :-)

> And your command example doesn't give you the ability to propagate it
> globally without even coding a single additional line of code. (none except
> warning messages we may want to introduce.)

True. But you could add [auto-changelists] to ~/.subversion/config...

(which doesn't solve the 'global propagation' problem, but helps a little)
Received on 2011-08-24 22:37:13 CEST

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