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.
-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 <cmpilato_at_collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
>
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2011-08-24 00:04:12 CEST