On 08/22/2011 02:01 AM, Greg Stein wrote:
> I find the entire concept to be worrisome. All of a sudden, there are
> files that just don't act right. "Magic" occurs, and only on certain
> files. This just isn't very discoverable, and I think it will just
> trip people up. "Huh? Why didn't that commit? ... OH, SUCK."
>
> There is just too much mystery occurring with this proposed feature.
On 08/22/2011 08:48 AM, Johan Corveleyn wrote:
> To me the current proposal seems like a relatively clean and standard
> approach. It doesn't appear to be any more magical than other svn:
> props (ignore, keywords, eol-style, ...). Besides, I haven't seen
> other ideas yet on how to implement this useful feature.
>
> However: please keep it as simple and transparent as possible, at
> least initially. For instance, I'm not interested in holding 'update'
> (I currently see no firm use case for that). AFAICS, the main thing is
> holding 'commit'. Though I realize that other operations may need to
> be adapted as well (status, diff, info, ...), to keep it consistent
> and understandable for the user.
I do understand Greg's concerns, and I particularly find the aspect
worrisome where it adds *yet* another way to 'svn merge' to shoot oneself in
the foot.
OTOH:
- I strongly agree that we do *not* hold updates or anything else, except
commit. (With wc-copies, we should probably not copy local mods though, and
a diff of local mods should omit held-back stuff. But that's *all*.)
- forgetting to issue --do-not-hold when committing a merge can be countered
by appropriate warnings at the bottom of merge output, which appear only
when held-back files are touched by a merge. If this is a major concern, we
could set some flag on affected files which makes 'commit' bail if
--do-not-hold is missing after a merge involving held-back nodes.
- #svn, the issue tracker (and probably the users@ list too though I haven't
checked) perpetually bring up this "template" problem. Tortoise has a per-WC
solution; we just have dumb workarounds, really.
- the level of magic around proposed 'svn:hold' is consistent with other
props. Plus, any and all such magic is obliterated simply by absence of
'svn:hold' propsets, and/or by --do-not-hold. What more can you ask for.
- any performance concerns can be addressed by adding a boolean column to
the NODES table, kept up-to-date by any prop changing code. I actually doubt
that this is even necessary.
The feature is still on the branch 'hold'. I'd love to merge to trunk in the
near future, since my roadmap is pretty quick to implement apparently. *Or*
I'd toss the whole concept out the window.
I'd appreciate to read more concerns *against* svn:hold on this list,
because if I eventually toss the feature, I might as well do so now.
OR I'LL JUST FORK SVN!! nah just kidding :)
Greg/anyone, do you have any more arguments against svn:hold except "people
will trip over a prop they read the documentation of and set up themselves
before it had any effect" -- because I don't think that's a real problem.
They would have tripped over 'svn:ignore', 'svn:externals' and
'svn:keywords' long before tripping over 'svn:hold'. BTW, my intention is to
clearly mark held-back local mods in 'svn status' (e.g. 'H'); particularly
important for merge situations.
In my vision, 'svn:hold' would be the exception, in the scale of one
build.conf type of file per huge project tree. But that's up to the users.
Which is exactly the point!
(See notes/hold for more points.)
Vote: Merge branches/hold to trunk soon?
neels: +1
Thanks for opinions!
~Neels
Received on 2011-08-22 16:33:16 CEST