You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@subversion.apache.org by Hyrum K Wright <hy...@wandisco.com> on 2011/08/24 00:03:42 UTC

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

On Tue, Aug 23, 2011 at 3:07 PM, C. Michael Pilato <cm...@collab.net> wrote:
> On 08/23/2011 11:59 AM, Neels J Hofmeyr wrote:
>> On 08/23/2011 10:32 AM, Julian Foad wrote:
>>> Mark (or anyone), do you recognize the use case described by Clemens
>>> Anhuth in <http://subversion.tigris.org/issues/show_bug.cgi?id=3028>?
>>>
>>>   Use case (2) - Eclipse folder, from issue #3028
>>>
>>>   "For example we have a complete Eclipse instance in our svn
>>>   repository and we want to ignore every change in its directory
>>>   and below. Because Eclipse more or less at random creates and
>>>   deletes file from its own directory we have no way of knowing
>>>   which individual files may be change or deleted by starting
>>>   Eclipse. To avoid that an update creates files again that were
>>>   deleted by running Eclipse the ignore setting I am asking for
>>>   should also apply to updates. [...]"
>>
>> That's quite a pickle. I'm not intending to make holding stuff recursive,
>> because then we'd have to check every commit target up into its ancestors,
>> possibly even checking if the *repos* has a hold set on an ancestor. Ugh.
>>
>> So svn:hold will not support this use case. Maybe they can trick something
>> up using externals, too....... uh........ *drop*  (<-- a penny)
>>
>> Come to think of it... we *do* have file externals, too.
>> And, my goodness, it *is* *already* possible to create a global hold on a
>> file using file externals. It is just less convenient:
>
> Oh, dude.  You're talking now about hacks based on hacks, here.  It makes me
> hurt.  :-)
>
> I, too, have wanted a first-class solution for the "template problem".  Many
> times.
>
> I, too, have also (but on much less frequent occasion) wanted to prevent
> incoming updates to a particular file.
>
> Now, I had always assumed the right solution for the latter of those was
> so-called "sticky revisions" (yes, in the same sense that CVS used the term
> "sticky" for its tags, but less automatic).  You would update a file to a
> particular revision with a special --sticky flag, and Subversion would
> remember until further notice that you want to keep that file (or
> directory!) at that particular revision.  It's kinda like our sticky depth
> handling today, in fact, just that we're locking stuff in time instead of in
> space.  Or something.
>
> Of course, I actually doubt that blocking updates is that compelling of a
> use-case, and suspect that in terms of functionality beneficial to the
> majority of Subversion users, it falls *well* behind the ability to avoid
> accidentally committing one's own changes to a file (which itself falls
> *well* behind a whole host of other, more important features, if we're being
> honest).  And when I think about where the very idea of blocking updates
> takes us in terms of how that might affect, oh, merges and such ... well, I
> get more than a little nauseous.
>
> So back to what I would consider the primary deliverable of interest here:
> avoiding one's own accidental commits.  I'm leaning toward a hostile
> takeover of the changelist namespace (a late-breaking land grab where we say
> "svn:<whatever>" is ours ours ours) and a changelist-based solution.  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'm not opposed to using the 'svn:' namespace for special changelists,
particularly since changelists aren't versioned, so you're not mucking
with data which may be in the historical record.  But special
changelists would be a nifty solution, we'd need to support multiple
changelists on a single item before going this route.  I wouldn't want
a special changelist to exclude standard ones.

-Hyrum

> But these are just my leanings.  I'm not deep enough into the consideration
> of all things relevant and tangential to formulate a clearer and more
> influential proposal.
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
>
>



-- 

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/

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

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.

Stefan Sperling wrote on Wed, Aug 24, 2011 at 16:51:43 +0200:
> On Wed, Aug 24, 2011 at 05:01:25PM +0300, 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
> 
> You have to specify --except-cl every time you commit.
> With svn:hold as a property you set it once and forget about it.

I was making a general point about changelists, not about their use in
conjunction with svn:hold feature.

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

Posted by Stefan Sperling <st...@elego.de>.

On Wed, Aug 24, 2011 at 05:01:25PM +0300, 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

You have to specify --except-cl every time you commit.
With svn:hold as a property you set it once and forget about it.

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

Posted by "C. Michael Pilato" <cm...@collab.net>.

On 08/24/2011 04:36 PM, Daniel Shahaf wrote:
> 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.

There should be no difference in behavior between subcommands.  The
documented behavior of changelists is to operate as filters only.  So, 'svn
$subcommand foo --changelist bar' operates on the subset of would-be targets
were --changelist not specified which are members of the specific changelist.

This means, for example, that 'svn info --changelist foo' will show nothing
because 'svn info' is depth-zero by default and directories can't be in
changelists, rather than showing all children of $CWD which are in the 'foo'
changelist.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

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

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.

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)

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

Posted by Neels J Hofmeyr <ne...@elego.de>.

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?

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.

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.)

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

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.

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

?