I don't get why you guys are even considering changelists :) What's the killer trait of changelists that makes this pig fly higher than a single lightweight boolean prop? I don't see one.
I think using changelists will end up being a Dirty Hack, either inconvenient or overly special-cased, no middle way available. It will spawn a lot of impenetrable code, compared to just a propget. If you're interested, read these elaborate reasons... Changelists have been *designed* in the flipped-over wrong-way-round: they *include*, not exclude selected items. We'd have to implement this against its basic design. (Like using switch for externals, remember?) Mark Phippard also talked about this kind of solution, adding a special changelist to exclude items from commit. I've thought it through long before proposing the svn:hold prop. My argument still holds: We'd have to change the changelists feature, beyond recognition. Instead of adding a quick propget in basically one or two places, we do what, overhaul changelists + plaster it with special conditions. But ok, we can do that. Still, the question remains: what about Johan & Co., that only have a use for ignore-on-commit if it is *centrally configurable*. You say, jolly, we just add the same prop neels proposed, to manipulate local changelists. But the prop alone is able to do the exact same thing without even touching changelists, and in fact would achieve the same goal with just a tiny patch of code; most of the infrastructure is already there, entirely for free, *exactly* in the way it is needed, no flipside special-casing required. User says: "what, I need to set a changelist *and* a prop? o_O" If we're *anyway* going to have a prop, which *does* provide all information needed, then I don't see any need to complicate this. If you're so eager to have a local-only implementation, just keep the prop out of the repos. (I wouldn't push that beyond telling users to add a pre-commit hook, though.) Do changelists make anything easier? - Yes, might spare us adding an 'H' notification on 'status'. - Changelists are kept out of version control. But svn:ignore-on-commit will be only as long as it remains a local feature. The exact same is achieved when the svn:hold propset is simply never committed. - No, changelists do not solve the 'merge-held-items' situation. After getting a merge in on an svn:ignore-on-commit'ed file, it is still not committed along with the rest of the merge, just like with a plain prop. Furthermore, if you do force a commit, then, guess what, the items silently disappear from the 'ignore-on-commit' changelist! Due to their basic design! Unless we add yet another special case there. Ugh. Or the merger person has to remember which they were and adds them back to the list manually. Ugh. You could argue that the global 'svn:hold' prop is still set, and after a merge-commit, you can automatically add those back to the changelist. I think this is a far more complex, slow and error-prone solution than what I proposed (just flag those files that were on hold and also received a merge, and block the commit until the user explicitly decides what to do, using a given cmdline option. Or by removing flags manually if desired). - (Sure, implementing this might gain the changelists feature some useful cmdline options, *if* we implement them in a general fashion instead of triggering on a special name only. -- that's besides the point though.) - (I guess that setting a prop on a node directly potentially makes faster code than employing a look-up in a special list. But this might actually not be true.) -1, IMO we should totally not have an svn:ignore-on-commit changelist. Though Tortoise devs might have liked that :) ~Neels
signature.asc
Description: OpenPGP digital signature
