[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 24 Aug 2011 19:26:52 +0200

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

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.