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
Received on 2011-08-24 15:33:05 CEST