On Wed, Aug 24, 2011 at 1:26 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> 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.
>
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 don't see how changelists could make this any easier. Could they?
>
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.
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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-08-24 19:34:03 CEST