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.
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
Received on 2011-08-23 22:07:36 CEST