[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: Hyrum K Wright <hyrum.wright_at_wandisco.com>
Date: Tue, 23 Aug 2011 17:03:42 -0500

On Tue, Aug 23, 2011 at 3:07 PM, C. Michael Pilato <cmpilato_at_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.


> 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 <cmpilato_at_collab.net>
> CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

uberSVN: Apache Subversion Made Easy
Received on 2011-08-24 00:04:12 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.