On Mon, Aug 22, 2011 at 2:01 AM, Greg Stein <gstein_at_gmail.com> wrote:
> On Sat, Aug 20, 2011 at 19:48, Neels J Hofmeyr <neels_at_elego.de> wrote:
>>...
>> I have taken the occasion to write a comprehensive description of my current
>> vision for svn:hold.
>
> 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.
FWIW, I do like this feature (as an svn user and overall CM person in
my company). I could certainly make good use of this in our
environment: for project and module files of the IDE, build scripts
("Makefile.in" and the like), ...
I do not want to bother every developer with that (putting them in a
changelist, ...), but just set it (and draft the template) centrally.
I only want them committed if someone explicitly decides to change the
template (--do-not-hold seems fine to me).
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.
--
Johan
Received on 2011-08-22 08:49:53 CEST