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
signature.asc
Description: OpenPGP digital signature
