2011/8/19 Neels J Hofmeyr <neels_at_elego.de>:
> Hi Daniel,
> if I understand you correctly, you are saying that there's no need for
> svn:hold, as changelists already do what they are supposed to do.
> But changelists and svn:hold have entirely different use cases.
> 1) svn:hold is exclusive, changelists are inclusive.
> I mean you can use an svn:hold on *one* file to block it, or you'd
> have to add *all other* files to a change list, what a bummer.
> 2) it should be possible to have svn:hold in the repos, i.e. to commit
> the property, using an --ignore-hold option, so that a project can
> by default set certain files on hold for all users checking out.
> I'm aware of changelists and I'm sure that changelists are not the solution
> to the use case at hand, being that there are few config files that are
> basically templates. Every user has to configure them for their local box
> (or every build changes some trivial item in it), and these changes should
> not be committed, unless the user is really sure. Every user is prone to
> committing these changes by accident and goes through pains to avoid
> committing them, on a daily basis. Every new user falls into the same pit at
> the first time, messing up all others' config files with conflicts. To work
> around, people have to think about custom build scripts, e.g. commiting the
> file on a different location and making the user/build script create a
> personal copy at the proper location. That solution is not satisfactory to
> many users.
> Does that clarify anything at all?
> And let me say this is bleeding edge WIP pre-alpha toy-around stuff on a
> branch, so don't take this seriously ... YET! ;)
TortoiseSVN has a predefined special changelist name
"ignore-on-commit". Items added to it are automatically not-selected
in commit dialog.
Isn't it the same thing?
Received on 2011-08-19 02:34:48 CEST