On Mon, Aug 22, 2011 at 19:19, Neels J Hofmeyr <neels_at_elego.de> wrote:
>...
> <steam-valve>
> So! If they want it, and if it's easy to implement, and if performance
> impact is low/unnoticeable/workaroundable, and if it's *optional* (usable
> local-only; and even cheaply, *optionally*, globally usable, for free, iff
> project management and pre-commit permit; we could even ship with svn:hold
> prohibiting code in the pre-commit template), and if Tortoise already does
> something almost similar...
> Then why the heck not?
> What's this growing discussion actually *about*?
> Auras and bikesheds?
You see something "obvious" to you because you've been thinking about
the problem and working on it. For the rest of us, this is new and (in
our minds) can introduce non-obvious and confusing behavior for our
users. That mental gap is what this thread is about: education.
>...
> So if 'svn:hold' *only* affects commit; Would I eventually be allowed to
> code this into trunk?
I'd give that a +1 if two things are implemented:
1) adjust the log message to note the hold-back
2) status shows 'H' for held files that also have local mods
>...
> And I can stay on the branch for a while to come, too. Would just be more
> convenient on trunk, cuts out all that merging.
I prefer trunk development. But only if you're talking about 'svn
commit', the log message changes, and 'svn status'. Affecting other
commands... then we get back into discussion :-)
btw, regarding 'svn diff' showing changes to held files: I think it
should. There are two types of changes to those held files:
local-only, and changes that you *want* to propagate to your
teammates. If you hide local mods, then a developer could miss the
need to commit the important work.
Cheers,
-g
Received on 2011-08-23 02:18:56 CEST