On Tue, Aug 23, 2011 at 3:07 PM, C. Michael Pilato <cmpil...@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 <cmpil...@collab.net> > CollabNet <> www.collab.net <> Distributed Development On Demand > > -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
