On Wed, Aug 24, 2011 at 01:33:33PM -0400, Mark Phippard wrote:
> You are thinking about this from the perspective of a developer and having
> them not accidentally commit their password. I am thinking of this from a
> merge meister type persona that has a clean working copy and is simply
> handling the merge tasks for a release. They would merge some revisions and
> do a commit that does not include all the changes. Other than some warnings
> they do not read, they would have no idea they lost changes.
I recognise that this can be a problem.
However, the merge meisters I've met are usually more competent
in using svn than the average developer in the same organisation.
Often they're even the local svn gurus. I would trust them to give
special consideration for files with svn:hold.
If the merge meister cannot handle this it's possible to fall back
to the template solution people are using now.
> Changelists potentially solve this problem in two distinct ways:
>
> 1) Suppose all we implement is a client-side changelist feature (like
> TortoiseSVN). In my scenario, since this is a client-initiated manual
> process it simply does not apply because the user has never set them up.
Right.
> 2) Suppose we add some automation, so that certain files are places on
> changelists automatically. Because we have two pieces to the puzzle, the
> changelist and the metadata that automatically puts the file on the
> changelist, we have more flexibility. Merge could simply be extended to
> automatically remove files from this special changelist. Likewise, commit
> could automatically put the files back on the changelist.
I don't like this because it only addresses the merge-meister use case.
Developers perform merges, too.
The developer who does not want to commit local changes that existed prior
to the merge now has to be careful to put files back on hold after the
merge command has removed files from the special changelist.
Received on 2011-08-24 19:51:03 CEST