On Wed, Aug 24, 2011 at 01:12:26PM -0400, Mark Phippard wrote:
> On Wed, Aug 24, 2011 at 1:09 PM, Stefan Sperling <stsp_at_elego.de> wrote:
>
> > On Wed, Aug 24, 2011 at 12:05:00PM -0400, Mark Phippard wrote:
> > > Merge remains a problem. Namely that if merge updates files with the
> > > svn:hold property the changes to those files will not be committed.
> >
> > I would say just let it be that way. It shouldn't matter whether
> > local mods come from merges or from manual edits.
> >
> > If the changes being merged into a held file are important,
> > then there's a user error -- the file should probably not
> > have been held in the first place.
> >
>
> I disagree. When I have wanted this feature in the past it has been for
> server apps where I have a default configuration file with various
> properties. Developers often need to insert passwords in these files and do
> not want to commit, but it is very common for the file to evolve over time
> and add new properties etc. I would want and expect those values to merge
> and commit between branches.
What is so special about merge? A merge creates local changes.
In the proposed design/implementation you can commit any local
changes by passing the --do-not-hold option.
Suppose you have a local file my-db.conf which contains a secret
database password as a local change.
You merge from another branch, and this sets the svn:eol-style
property on this file.
You want to keep the propchange, but don't want to commit the
password.
The solution is to temporarily remove the password from the file,
commit the file (i.e. just the propchange) with --do-not-hold,
and then add the password back.
I don't see how changelists could make this any easier. Could they?
Received on 2011-08-24 19:27:40 CEST