On Wed, Aug 24, 2011 at 12:03 AM, Hyrum K Wright
<hyrum.wright_at_wandisco.com> wrote:
> 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.
IMHO simply using changelists lacks the most important part of the
feature: the ability to set/configure/annotate this centrally. I'm not
particularly interested in a feature that forces me (as a CM) to
remind every developer that they should put the IDE project file into
their ignore-changelist after checking it out. To me that's like
having to remind them to configure the correct autoprops, or set
certain properties manually (repository-dictated autoprops, anyone?).
The question about the "template" comes up quite regularly on the
users list (not as often as questions about subtree mergeinfo or tree
conflicts, or say "authz with wildcards", but still once in a while --
and it's a FAQ after all). It's almost always in relation to IDE
project or configuration files, or makefiles, buildscripts, etc ...
Things that, in most teams, are maintained by a handful of people, but
read/used by a lot of other developers when setting up their
environment (after which the files are locally edited with
user-specific stuff).
That said, I'm not sure either that svn:hold (the property) is the
best approach (I haven't really thought through all those edge cases).
But it seems to me that it could work. OTOH, I haven't really seen
better suggestions (which keep it centrally configured).
--
Johan
Received on 2011-08-24 00:09:06 CEST