You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Neels J Hofmeyr <ne...@elego.de> on 2011/08/21 01:48:16 UTC
concerns about svn:hold -- was: svn commit: r1159240 - in /subversion/branches/hold/subversion:
include/private/svn_wc_private.h include/svn_props.h libsvn_client/commit_util.c
libsvn_wc/node.c
On 08/20/2011 03:13 AM, Mark Phippard wrote:
[...]
> That said, some of these questions concern me. Have you outlined your
> vision for this feature in its entirety? The idea that svn up would not
> update these files scares me. I have never heard anyone ask for anything
> but having an easy way to exclude some files from commit. IMO, other
> operations like update/merge/switch ought to all do their normal behavior
> and not be impacted by a special property.
>
> I also wonder about commit performance. Does WC-NG make this a non-issue?
> I would imagine having to do a property check on every file could become
> expensive, but at the same time with a focused and tuned SQL query it could
> probably be negligible.
Hi Mark,
thanks for these excellent questions.
I have taken the occasion to write a comprehensive description of my current
vision for svn:hold.
I share your reservation about holding back updates, but it is being
mentioned in two issues (#2858 and #3028), so we better have an answer for it.
There naturally is some inconvenience about merging held-back files, because
the merge result should usually always be committed. So mergers have to
remember to --do-not-hold when committing merges.
Commit performance loss is only an issue when there are very many files that
are modified, as the property only needs to be checked on files that are
modified in some way (at the very "tip" of harvest_committables()).
Well, I should stop repeating what's already said in notes/hold. I hope that
the outline is satisfactory, and please hint me at topics I might have
missed in there!
http://svn.apache.org/repos/asf/subversion/trunk/notes/hold
~Neels
Re: concerns about svn:hold -- was: svn commit: r1159240 - in /subversion/branches/hold/subversion: include/private/svn_wc_private.h include/svn_props.h libsvn_client/commit_util.c libsvn_wc/node.c
Posted by Gavin Baumanis <ga...@thespidernet.com>.
Hi Neels,
For the time I have been writing this email I have struggled to find a use-case where "I" would use your new feature proposa
None the less; I really like the idea.
It really isn't changing anything of real substance from the users point of view.
* It just simplifies my commit processes because now I no longer have to manually exclude a file from being committed.
* A temporary svn:ignore until I "actively" choose to commit it.
As for the concern about whether to update the file on hold or not... I don;t have a string opinion either way.
Is there any possibility of having that behaviour an option?
I.e. chose to have a held file updated or not - as opposed to having it dictated to the end-user?
Gavin
On 21/08/2011, at 9:48 AM, Neels J Hofmeyr wrote:
> On 08/20/2011 03:13 AM, Mark Phippard wrote:
> [...]
>> That said, some of these questions concern me. Have you outlined your
>> vision for this feature in its entirety? The idea that svn up would not
>> update these files scares me. I have never heard anyone ask for anything
>> but having an easy way to exclude some files from commit. IMO, other
>> operations like update/merge/switch ought to all do their normal behavior
>> and not be impacted by a special property.
>>
>> I also wonder about commit performance. Does WC-NG make this a non-issue?
>> I would imagine having to do a property check on every file could become
>> expensive, but at the same time with a focused and tuned SQL query it could
>> probably be negligible.
>
> Hi Mark,
>
> thanks for these excellent questions.
> I have taken the occasion to write a comprehensive description of my current
> vision for svn:hold.
>
> I share your reservation about holding back updates, but it is being
> mentioned in two issues (#2858 and #3028), so we better have an answer for it.
>
> There naturally is some inconvenience about merging held-back files, because
> the merge result should usually always be committed. So mergers have to
> remember to --do-not-hold when committing merges.
>
> Commit performance loss is only an issue when there are very many files that
> are modified, as the property only needs to be checked on files that are
> modified in some way (at the very "tip" of harvest_committables()).
>
> Well, I should stop repeating what's already said in notes/hold. I hope that
> the outline is satisfactory, and please hint me at topics I might have
> missed in there!
>
> http://svn.apache.org/repos/asf/subversion/trunk/notes/hold
>
> ~Neels
>
Re: concerns about svn:hold -- was: svn commit: r1159240 - in /subversion/branches/hold/subversion:
include/private/svn_wc_private.h include/svn_props.h libsvn_client/commit_util.c
libsvn_wc/node.c
Posted by Neels J Hofmeyr <ne...@elego.de>.
Forgot to add that I absolutely love & agree with this reply. Thanks Johan!
~Neels
On 08/22/2011 08:48 AM, Johan Corveleyn wrote:
> On Mon, Aug 22, 2011 at 2:01 AM, Greg Stein <gs...@gmail.com> wrote:
>> On Sat, Aug 20, 2011 at 19:48, Neels J Hofmeyr <ne...@elego.de> wrote:
>>> ...
>>> I have taken the occasion to write a comprehensive description of my current
>>> vision for svn:hold.
>>
>> I find the entire concept to be worrisome. All of a sudden, there are
>> files that just don't act right. "Magic" occurs, and only on certain
>> files. This just isn't very discoverable, and I think it will just
>> trip people up. "Huh? Why didn't that commit? ... OH, SUCK."
>>
>> There is just too much mystery occurring with this proposed feature.
>
> FWIW, I do like this feature (as an svn user and overall CM person in
> my company). I could certainly make good use of this in our
> environment: for project and module files of the IDE, build scripts
> ("Makefile.in" and the like), ...
>
> I do not want to bother every developer with that (putting them in a
> changelist, ...), but just set it (and draft the template) centrally.
> I only want them committed if someone explicitly decides to change the
> template (--do-not-hold seems fine to me).
>
> To me the current proposal seems like a relatively clean and standard
> approach. It doesn't appear to be any more magical than other svn:
> props (ignore, keywords, eol-style, ...). Besides, I haven't seen
> other ideas yet on how to implement this useful feature.
>
> However: please keep it as simple and transparent as possible, at
> least initially. For instance, I'm not interested in holding 'update'
> (I currently see no firm use case for that). AFAICS, the main thing is
> holding 'commit'. Though I realize that other operations may need to
> be adapted as well (status, diff, info, ...), to keep it consistent
> and understandable for the user.
>
AW: bring on your concerns about svn:hold, please
Posted by Markus Schaber <m....@3s-software.com>.
Hi,
Von: Greg Stein [mailto:gstein@gmail.com]
> On Mon, Aug 22, 2011 at 15:34, Daniel Shahaf <da...@elego.de> wrote:
> > Greg Stein wrote on Mon, Aug 22, 2011 at 14:46:16 -0400:
> >...
> > Same thing if someone else sets svn:ignore and you have a local
> >addition you hadn't told svn about yet.
> >
> > How would you explain that behaviour? Perhaps by saying Alice should
> > have warned Bob that she'd set svn:ignore? And however you explain it
> > --- why doesn't the same explanation apply to svn:hold?
>
> 'svn add foo' will *always* work, regardless of the svn:ignore setting.
> The property only applies for recursive adds. During your 'add', it is
> also quite easy to see the file was not added. So you just 'svn add
> foo/bar'.
>
> 'svn commit foo' will *never* work if svn:hold is set on the file. I find
> that awfully confusing, until I realize that somebody applied svn:hold to
> the file.
Maybe svn:hold should be a little bit more like "svn:ignore" and the "ignore-on-commit" in TortoiseSVN: There, it is not selected by default in the commit dialog, but it can be manually selected.
So files with svn:hold are not selected by recursive commits, or by naming changelists containing them, but they can be committed by naming them explicitly (maybe with a further warning or confirmation).
Mit freundlichen Grüßen
Markus Schaber
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Entwicklung
Memminger Str. 151 | 87439 Kempten | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
CoDeSys Internet-Forum: http://forum.3s-software.com
Geschäftsführer: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Handelsregister: Kempten HRB 6186 | USt-IDNr.: DE 167014915
Re: bring on your concerns about svn:hold, please
Posted by Neels J Hofmeyr <ne...@elego.de>.
On 08/23/2011 01:22 AM, Neels J Hofmeyr wrote:
> On 08/23/2011 12:00 AM, Greg Stein wrote:
>> 'svn commit foo' will *never* work if svn:hold is set on the file. I
>> find that awfully confusing, until I realize that somebody applied
>> svn:hold to the file.
>
> That's actually an intended part of the feature, and it is
> switch-off-and-rule-out-able forever by a simple pre-commit hook. With no
> svn:hold allowed to be committed, it remains usable locally. I don't see
> *any* problem here.
Actually, if you do still see a problem, what about adding another option
--commit-global-hold (or whatever the name) without which even --do-not-hold
keeps the 'svn:hold' property out of the repository.
I mean if 'svn:hold' is set locally on 'foo' and 'foo' gets committed with
--do-not-hold, the local text and other mods *are* committed, but only the
'svn:hold' propset is still held back.
Add --commit-global-hold to do leak it into the repos, definitely
intentionally. Just to add another threshold before sending 'hold' to other WCs.
I'd gladly implement this if this list thinks it would be good to add this
step. (IMO it's not really necessary.)
~Neels
Re: bring on your concerns about svn:hold, please
Posted by Neels J Hofmeyr <ne...@elego.de>.
On 08/23/2011 12:00 AM, Greg Stein wrote:
> 'svn commit foo' will *never* work if svn:hold is set on the file. I
> find that awfully confusing, until I realize that somebody applied
> svn:hold to the file.
That's actually an intended part of the feature, and it is
switch-off-and-rule-out-able forever by a simple pre-commit hook. With no
svn:hold allowed to be committed, it remains usable locally. I don't see
*any* problem here.
~Neels
Re: bring on your concerns about svn:hold, please
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Aug 22, 2011 at 15:34, Daniel Shahaf <da...@elego.de> wrote:
> Greg Stein wrote on Mon, Aug 22, 2011 at 14:46:16 -0400:
>...
> Same thing if someone else sets svn:ignore and you have a local addition
> you hadn't told svn about yet.
>
> How would you explain that behaviour? Perhaps by saying Alice should
> have warned Bob that she'd set svn:ignore? And however you explain it
> --- why doesn't the same explanation apply to svn:hold?
'svn add foo' will *always* work, regardless of the svn:ignore
setting. The property only applies for recursive adds. During your
'add', it is also quite easy to see the file was not added. So you
just 'svn add foo/bar'.
'svn commit foo' will *never* work if svn:hold is set on the file. I
find that awfully confusing, until I realize that somebody applied
svn:hold to the file.
Cheers,
-g
Re: bring on your concerns about svn:hold, please
Posted by Daniel Shahaf <da...@elego.de>.
Greg Stein wrote on Mon, Aug 22, 2011 at 14:46:16 -0400:
> On Mon, Aug 22, 2011 at 10:32, Neels J Hofmeyr <ne...@elego.de> wrote:
> >...
> > Greg/anyone, do you have any more arguments against svn:hold except "people
> > will trip over a prop they read the documentation of and set up themselves
> > before it had any effect" -- because I don't think that's a real problem.
> > They would have tripped over 'svn:ignore', 'svn:externals' and
> > 'svn:keywords' long before tripping over 'svn:hold'. BTW, my intention is to
>
> svn:ignore affects status and add. If a file is *already*
> version-controlled, then it has no impact.
>
> svn:externals is a way to stitch together multiple working copies of
> version-controlled nodes.
>
> svn:keywords merely affects expansion in a working copy. There is no
> operational impact.
>
> ... but svn:hold? That alters the very operation of a
> version-controlled file. Now, all of a sudden... it does not
> participate in a commit. If somebody set the value *locally*, then I
> say "fine. they did it. they should know". But this thing can go into
> the repository, and then just appear in my working copy. And out of
> nowhere, my files don't commit like they should.
Same thing if someone else sets svn:ignore and you have a local addition
you hadn't told svn about yet.
How would you explain that behaviour? Perhaps by saying Alice should
have warned Bob that she'd set svn:ignore? And however you explain it
--- why doesn't the same explanation apply to svn:hold?
===
Random thought: We could have 'svn update' output warn when such special
properties (svn:ignore, svn:add, svn:server-dictated-hook, svn:repository-
dictated-config) are added by an update.
Re: bring on your concerns about svn:hold, please
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Aug 22, 2011 at 10:32, Neels J Hofmeyr <ne...@elego.de> wrote:
>...
> Greg/anyone, do you have any more arguments against svn:hold except "people
> will trip over a prop they read the documentation of and set up themselves
> before it had any effect" -- because I don't think that's a real problem.
> They would have tripped over 'svn:ignore', 'svn:externals' and
> 'svn:keywords' long before tripping over 'svn:hold'. BTW, my intention is to
svn:ignore affects status and add. If a file is *already*
version-controlled, then it has no impact.
svn:externals is a way to stitch together multiple working copies of
version-controlled nodes.
svn:keywords merely affects expansion in a working copy. There is no
operational impact.
... but svn:hold? That alters the very operation of a
version-controlled file. Now, all of a sudden... it does not
participate in a commit. If somebody set the value *locally*, then I
say "fine. they did it. they should know". But this thing can go into
the repository, and then just appear in my working copy. And out of
nowhere, my files don't commit like they should.
And now you're saying that it affects more than commit. Diffs? Copies?
If you limit it to *just* commits, and if the generated log message
would say something like, "The following files are being held from
commit:\nH some/path/foo \nH other/path/bar\n", then I'd be more
supportive. When somebody goes to commit, then it is very clear these
files are not participating. (and yes, showing 'H' in status is a good
thing, with the understanding it means "modified, but being held"; the
file should not show at all, if unmodified)
I think 'svn diff' should continue to show the local modifications.
And it should be copied just like any other file. And that may mean
copying with the local mods. When committing that copy, a copy will be
performed on the server, but the local mods will not reach the server
due to the svn:hold.
Cheers,
-g
Re: bring on your concerns about svn:hold, please
Posted by Neels J Hofmeyr <ne...@elego.de>.
On 08/23/2011 03:56 PM, Hyrum K Wright wrote:
>>>> btw, regarding 'svn diff' showing changes to held files: I think it
>>>> should.
>>> +1 'svn diff' should still show mods to held files.
>>
>> humph, ok, if you say so. I'd add a --do-hold option to diff then.
>
> Are you saying diff would hide files by default, and then expose them
> with the option, or vice versa? I'm in favor of the latter (do no
> hiding by default).
Yeah, I'm saying "fine, do not hide by default, but have a --do-hold option
that allows hiding if user wants to." Because I think hiding held files is
quite useful.
>>> Another consideration is that properties live forever, possibly even
>>> past some eventual 2.0, and when implementing new special props,
>>> conservative is definitely the way to go. We can always add more; we
>>> can't ever take them away.
>>
>> That's a really good point. Though we technically *could* simply stop
>> heeding certain props in a future version.
Gotcha, svn would still have to heed the prop when called via 1.8 API, for
example. But I guess for 2.0, everything is allowed. *If* there will be a 2.0.
~Neels
Re: bring on your concerns about svn:hold, please
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Tue, Aug 23, 2011 at 8:49 AM, Neels J Hofmeyr <ne...@elego.de> wrote:
> On 08/23/2011 03:04 AM, Hyrum K Wright wrote:
>> On Mon, Aug 22, 2011 at 7:18 PM, Greg Stein <gs...@gmail.com> wrote:
>>> I'd give that a +1 if two things are implemented:
>>>
>>> 1) adjust the log message to note the hold-back 2) status shows 'H'
>>> for held files that also have local mods
>
> Ok, cool.
>
>>> btw, regarding 'svn diff' showing changes to held files: I think it
>>> should.
>> +1 'svn diff' should still show mods to held files.
>
> humph, ok, if you say so. I'd add a --do-hold option to diff then.
Are you saying diff would hide files by default, and then expose them
with the option, or vice versa? I'm in favor of the latter (do no
hiding by default).
-Hyrum
>
>
>
>> I think we don't need to be talking about a one-size-fits-all approach
>> here. While I don't think an explosion of special properties is good
>> either, a well chosen set which handle the various behaviors people
>> want may be a better solution than an 'svn:hold' attempting to be all
>> things to all people.
>
> So far, I had the impression that implementing it this way simply *is* all
> things to all people. What differences in behavior would you separate?
>
>> Another consideration is that properties live forever, possibly even
>> past some eventual 2.0, and when implementing new special props,
>> conservative is definitely the way to go. We can always add more; we
>> can't ever take them away.
>
> That's a really good point. Though we technically *could* simply stop
> heeding certain props in a future version. Just the name is taken forever,
> right? I don't think we're taking that much of a risk with svn:hold; but:
>
> The part I'm most conservative about is how it affects merge.
>
> svn ps svn:hold foo
> [...]
> svn merge ^/trunk
> U foo
> U bar
> svn st
> HH foo
> M bar
> svn ci -mm
> Sending bar.....
> svn st
> HH foo
>
> If someone did not 'svn status', they'd be annoyed to see 'foo' missing from
> the commit of the merge. According to you, 'svn diff' also shows the merge
> mods on 'foo', but they don't get committed. "huh, what?"
>
> This is a situation mergers could whine about. All of a sudden they have to
> take care about files someone else chose to put on hold globally, and why
> did project management allow that anyway.
>
> But I've talked about solutions, like project management deciding not to
> allow this by means of a pre-commit, and this one:
>
> svn ps svn:hold foo
> [...]
> svn merge ^/trunk
> U foo
> U bar
> svn pl -v foo
> Properties on 'foo':
> svn:hold
> *
> svn:hold-merged
> *
> svn ci -mm
> svn: You have merged held-back files (see status output).
> svn: Please supply either --do-not-hold or --do-hold, explicitly.
> svn ci --do-not-hold
> Sending foo.....
> Sending bar.....
> svn pl -v foo
> Properties on 'foo':
> svn:hold
> *
>
> Do you think we're likely to regret having created (letting neels create)
> this kind of situation? That's the part I'm most unsure about. All the rest
> seems to be lesser peanuts to me.
>
> ~Neels
>
>
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: bring on your concerns about svn:hold, please
Posted by Neels J Hofmeyr <ne...@elego.de>.
On 08/23/2011 03:04 AM, Hyrum K Wright wrote:
> On Mon, Aug 22, 2011 at 7:18 PM, Greg Stein <gs...@gmail.com> wrote:
>> I'd give that a +1 if two things are implemented:
>>
>> 1) adjust the log message to note the hold-back 2) status shows 'H'
>> for held files that also have local mods
Ok, cool.
>> btw, regarding 'svn diff' showing changes to held files: I think it
>> should.
> +1 'svn diff' should still show mods to held files.
humph, ok, if you say so. I'd add a --do-hold option to diff then.
> I think we don't need to be talking about a one-size-fits-all approach
> here. While I don't think an explosion of special properties is good
> either, a well chosen set which handle the various behaviors people
> want may be a better solution than an 'svn:hold' attempting to be all
> things to all people.
So far, I had the impression that implementing it this way simply *is* all
things to all people. What differences in behavior would you separate?
> Another consideration is that properties live forever, possibly even
> past some eventual 2.0, and when implementing new special props,
> conservative is definitely the way to go. We can always add more; we
> can't ever take them away.
That's a really good point. Though we technically *could* simply stop
heeding certain props in a future version. Just the name is taken forever,
right? I don't think we're taking that much of a risk with svn:hold; but:
The part I'm most conservative about is how it affects merge.
svn ps svn:hold foo
[...]
svn merge ^/trunk
U foo
U bar
svn st
HH foo
M bar
svn ci -mm
Sending bar.....
svn st
HH foo
If someone did not 'svn status', they'd be annoyed to see 'foo' missing from
the commit of the merge. According to you, 'svn diff' also shows the merge
mods on 'foo', but they don't get committed. "huh, what?"
This is a situation mergers could whine about. All of a sudden they have to
take care about files someone else chose to put on hold globally, and why
did project management allow that anyway.
But I've talked about solutions, like project management deciding not to
allow this by means of a pre-commit, and this one:
svn ps svn:hold foo
[...]
svn merge ^/trunk
U foo
U bar
svn pl -v foo
Properties on 'foo':
svn:hold
*
svn:hold-merged
*
svn ci -mm
svn: You have merged held-back files (see status output).
svn: Please supply either --do-not-hold or --do-hold, explicitly.
svn ci --do-not-hold
Sending foo.....
Sending bar.....
svn pl -v foo
Properties on 'foo':
svn:hold
*
Do you think we're likely to regret having created (letting neels create)
this kind of situation? That's the part I'm most unsure about. All the rest
seems to be lesser peanuts to me.
~Neels
Re: bring on your concerns about svn:hold, please
Posted by Greg Stein <gs...@gmail.com>.
On Aug 22, 2011 9:04 PM, "Hyrum K Wright" <hy...@wandisco.com> wrote:
>...
> > I'd give that a +1 if two things are implemented:
> >
> > 1) adjust the log message to note the hold-back
>
> Are you talking about the suggested log message that appears in
> $EDITOR, or munging the log message in flight? I'm fine with the
> former, but the latter feels it's a huge minefield.
The former, certainly.
>...
Cheers,
-g
Re: bring on your concerns about svn:hold, please
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Mon, Aug 22, 2011 at 7:18 PM, Greg Stein <gs...@gmail.com> wrote:
> On Mon, Aug 22, 2011 at 19:19, Neels J Hofmeyr <ne...@elego.de> wrote:
>>...
>> So if 'svn:hold' *only* affects commit; Would I eventually be allowed to
>> code this into trunk?
I think we don't need to be talking about a one-size-fits-all approach
here. While I don't think an explosion of special properties is good
either, a well chosen set which handle the various behaviors people
want may be a better solution than an 'svn:hold' attempting to be all
things to all people.
Another consideration is that properties live forever, possibly even
past some eventual 2.0, and when implementing new special props,
conservative is definitely the way to go. We can always add more; we
can't ever take them away.
> I'd give that a +1 if two things are implemented:
>
> 1) adjust the log message to note the hold-back
Are you talking about the suggested log message that appears in
$EDITOR, or munging the log message in flight? I'm fine with the
former, but the latter feels it's a huge minefield.
> 2) status shows 'H' for held files that also have local mods
>
>>...
>> And I can stay on the branch for a while to come, too. Would just be more
>> convenient on trunk, cuts out all that merging.
>
> I prefer trunk development. But only if you're talking about 'svn
> commit', the log message changes, and 'svn status'. Affecting other
> commands... then we get back into discussion :-)
By limiting the scope as I mention above, it's much easier to
implement on trunk.
> btw, regarding 'svn diff' showing changes to held files: I think it
> should. There are two types of changes to those held files:
> local-only, and changes that you *want* to propagate to your
> teammates. If you hide local mods, then a developer could miss the
> need to commit the important work.
+1 'svn diff' should still show mods to held files.
Feel free to introduce some option to diff which could potentially
screen files with this property, but as the default behavior, 'svn
diff' should show all mods to a working copy.
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: bring on your concerns about svn:hold, please
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Aug 22, 2011 at 19:19, Neels J Hofmeyr <ne...@elego.de> wrote:
>...
> <steam-valve>
> So! If they want it, and if it's easy to implement, and if performance
> impact is low/unnoticeable/workaroundable, and if it's *optional* (usable
> local-only; and even cheaply, *optionally*, globally usable, for free, iff
> project management and pre-commit permit; we could even ship with svn:hold
> prohibiting code in the pre-commit template), and if Tortoise already does
> something almost similar...
> Then why the heck not?
> What's this growing discussion actually *about*?
> Auras and bikesheds?
You see something "obvious" to you because you've been thinking about
the problem and working on it. For the rest of us, this is new and (in
our minds) can introduce non-obvious and confusing behavior for our
users. That mental gap is what this thread is about: education.
>...
> So if 'svn:hold' *only* affects commit; Would I eventually be allowed to
> code this into trunk?
I'd give that a +1 if two things are implemented:
1) adjust the log message to note the hold-back
2) status shows 'H' for held files that also have local mods
>...
> And I can stay on the branch for a while to come, too. Would just be more
> convenient on trunk, cuts out all that merging.
I prefer trunk development. But only if you're talking about 'svn
commit', the log message changes, and 'svn status'. Affecting other
commands... then we get back into discussion :-)
btw, regarding 'svn diff' showing changes to held files: I think it
should. There are two types of changes to those held files:
local-only, and changes that you *want* to propagate to your
teammates. If you hide local mods, then a developer could miss the
need to commit the important work.
Cheers,
-g
Re: bring on your concerns about svn:hold, please
Posted by Julian Foad <ju...@wandisco.com>.
Neels, I hadn't read through your 'notes/hold' doc, which I should have
done first. Now I have, and added a bunch of comments - see attached
patch.
It would be really helpful if, in the light of your current knowledge
and what's been discussed in this thread, you could update that doc and
convert it (or part of it) into a complete user reference manual
section, describing first the principles and then the exact intended
behaviour:
"The idea is X ... The new principles are X ... In terms of selecting
what to commit it works exactly like X except X ... The exact behaviour
of every affected operation is X ... Behaviours that might surprise you
at first are X ..."
You could put '### Not impl' or '### Currently does X instead of Y'
markers where applicable. Move possible alternatives into footnotes or
into a different section so we'd have a single complete description on
which to base any further discussion.
Where you replied to my question about diff:
> > And what's this about local-diff? You intend to ignore the whole
> > file that is 'held'? Or do you intend to print diffs of [...]
> I use 'svn diff' to check the local modifications that are going to be
> committed. Right?? How is it obscure to omit local modifications on a
> held-back file? (All mods that are already committed *are* shown.)
I was not saying we shouldn't affect diffs, I was asking exactly what
you intend, because I hadn't thought it through and it wasn't clear.
Now I've thought it through a bit more and put my notes in the attached
patch, but you may have more to say on it. I still don't understand
"All mods that are already committed *are* shown"; you can't be talking
about a local diff?
About copies: I've noted in the patch that I think copy should not
silently ignore local mods, because those mods might be intentional and
important. Instead, commit should error out, although I'm not precise
about the details. Maybe error on any attempt to commit the
add/del/cp/mv/replace of a held-back file if not overridden.
In my comments I say only the working props (and not the base props) of
the file should determine whether it's held back. That's because I
think that definition plays well with nearly all the other behaviour. I
first started to write things like "if the base and/or working version
has the prop ..." and that got messy and unnecessary. But I haven't
fully resolved how this affects deleting the file: a schedule-delete
file logically has no working props.
- Julian
Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long
live file externals?? (and discussing recursive hold)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Wed, Aug 24, 2011 at 16:51:43 +0200:
> On Wed, Aug 24, 2011 at 05:01:25PM +0300, Daniel Shahaf wrote:
> > Neels J Hofmeyr wrote on Wed, Aug 24, 2011 at 15:32:20 +0200:
> > > Changelists have been *designed* in the flipped-over wrong-way-round: they
> > > *include*, not exclude selected items. We'd have to implement this against
> > > its basic design. (Like using switch for externals, remember?)
> >
> > Changelists were designed to group files. What's fundamentally flawed in
> >
> > % svn cl foo A/mu ./iota
> > % svn commit --depth=empty A/mu ./iota --except-cl=foo
>
> You have to specify --except-cl every time you commit.
> With svn:hold as a property you set it once and forget about it.
I was making a general point about changelists, not about their use in
conjunction with svn:hold feature.
Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long
live file externals?? (and discussing recursive hold)
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Aug 24, 2011 at 05:01:25PM +0300, Daniel Shahaf wrote:
> Neels J Hofmeyr wrote on Wed, Aug 24, 2011 at 15:32:20 +0200:
> > Changelists have been *designed* in the flipped-over wrong-way-round: they
> > *include*, not exclude selected items. We'd have to implement this against
> > its basic design. (Like using switch for externals, remember?)
>
> Changelists were designed to group files. What's fundamentally flawed in
>
> % svn cl foo A/mu ./iota
> % svn commit --depth=empty A/mu ./iota --except-cl=foo
You have to specify --except-cl every time you commit.
With svn:hold as a property you set it once and forget about it.
Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long
live file externals?? (and discussing recursive hold)
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 08/24/2011 04:36 PM, Daniel Shahaf wrote:
> Neels J Hofmeyr wrote on Wed, Aug 24, 2011 at 22:04:11 +0200:
>> On 08/24/2011 04:01 PM, Daniel Shahaf wrote:
>>> Neels J Hofmeyr wrote on Wed, Aug 24, 2011 at 15:32:20 +0200:
>>>> Changelists have been *designed* in the flipped-over wrong-way-round: they
>>>> *include*, not exclude selected items. We'd have to implement this against
>>>> its basic design. (Like using switch for externals, remember?)
>>>
>>> Changelists were designed to group files. What's fundamentally flawed in
>>>
>>> % svn cl foo A/mu ./iota
>>> % svn commit --depth=empty A/mu ./iota --except-cl=foo
>>
>> Usually the code goes like "if there is a changelist, act on the node only
>> when it is part of the changelist." ...well, it's just what I remember
>> faintly, admittedly. Is that true?
>>
>
> My recollection is that 'svn $subcommand foo --changelist bar' applies
> to one of:
>
> - the subset of descendants of that are in changelist 'bar';
> - both to foo and to members of 'bar'
>
> where some subcommands behave differently than others.
There should be no difference in behavior between subcommands. The
documented behavior of changelists is to operate as filters only. So, 'svn
$subcommand foo --changelist bar' operates on the subset of would-be targets
were --changelist not specified which are members of the specific changelist.
This means, for example, that 'svn info --changelist foo' will show nothing
because 'svn info' is depth-zero by default and directories can't be in
changelists, rather than showing all children of $CWD which are in the 'foo'
changelist.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long
live file externals?? (and discussing recursive hold)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Neels J Hofmeyr wrote on Wed, Aug 24, 2011 at 22:04:11 +0200:
> On 08/24/2011 04:01 PM, Daniel Shahaf wrote:
> > Neels J Hofmeyr wrote on Wed, Aug 24, 2011 at 15:32:20 +0200:
> >> Changelists have been *designed* in the flipped-over wrong-way-round: they
> >> *include*, not exclude selected items. We'd have to implement this against
> >> its basic design. (Like using switch for externals, remember?)
> >
> > Changelists were designed to group files. What's fundamentally flawed in
> >
> > % svn cl foo A/mu ./iota
> > % svn commit --depth=empty A/mu ./iota --except-cl=foo
>
> Usually the code goes like "if there is a changelist, act on the node only
> when it is part of the changelist." ...well, it's just what I remember
> faintly, admittedly. Is that true?
>
My recollection is that 'svn $subcommand foo --changelist bar' applies
to one of:
- the subset of descendants of that are in changelist 'bar';
- both to foo and to members of 'bar'
where some subcommands behave differently than others.
> If it isn't, there's nothing wrong with your command at all. In fact that
> would be quite nice.
>
> But from the ignore-on-commit perspective, you still need to remember to
> supply it at commit time.
> You'd need to make the changelist always secretly self-acting, and thus the
> changelist must have a special name, as Hyrum kindly pointed out :)
> If I can instead create a simple property to achieve the same, I'm happier.
>
We could decide that the special changelist is always applied, unless
a node has been explicitly named as a commit target. It wouldn't even
require a revision of the API signature :-)
> And your command example doesn't give you the ability to propagate it
> globally without even coding a single additional line of code. (none except
> warning messages we may want to introduce.)
>
True. But you could add [auto-changelists] to ~/.subversion/config...
(which doesn't solve the 'global propagation' problem, but helps a little)
Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long
live file externals?? (and discussing recursive hold)
Posted by Neels J Hofmeyr <ne...@elego.de>.
On 08/24/2011 04:01 PM, Daniel Shahaf wrote:
> Neels J Hofmeyr wrote on Wed, Aug 24, 2011 at 15:32:20 +0200:
>> Changelists have been *designed* in the flipped-over wrong-way-round: they
>> *include*, not exclude selected items. We'd have to implement this against
>> its basic design. (Like using switch for externals, remember?)
>
> Changelists were designed to group files. What's fundamentally flawed in
>
> % svn cl foo A/mu ./iota
> % svn commit --depth=empty A/mu ./iota --except-cl=foo
Usually the code goes like "if there is a changelist, act on the node only
when it is part of the changelist." ...well, it's just what I remember
faintly, admittedly. Is that true?
If it isn't, there's nothing wrong with your command at all. In fact that
would be quite nice.
But from the ignore-on-commit perspective, you still need to remember to
supply it at commit time.
You'd need to make the changelist always secretly self-acting, and thus the
changelist must have a special name, as Hyrum kindly pointed out :)
If I can instead create a simple property to achieve the same, I'm happier.
And your command example doesn't give you the ability to propagate it
globally without even coding a single additional line of code. (none except
warning messages we may want to introduce.)
Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long
live file externals?? (and discussing recursive hold)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Neels J Hofmeyr wrote on Wed, Aug 24, 2011 at 15:32:20 +0200:
> Changelists have been *designed* in the flipped-over wrong-way-round: they
> *include*, not exclude selected items. We'd have to implement this against
> its basic design. (Like using switch for externals, remember?)
Changelists were designed to group files. What's fundamentally flawed in
% svn cl foo A/mu ./iota
% svn commit --depth=empty A/mu ./iota --except-cl=foo
?
Re: dump svn:hold, long live file externals?? (and discussing
recursive hold) -- was: bring on your concerns about svn:hold, please
Posted by Julian Foad <ju...@wandisco.com>.
Daniel Shahaf wrote:
> Julian Foad wrote on Wed, Aug 24, 2011 at 13:23:53 +0100:
> > On Wed, 2011-08-24 at 15:10 +0300, Daniel Shahaf wrote:
> > > Julian Foad wrote on Wed, Aug 24, 2011 at 11:13:09 +0100:
> > > > The set of changelists to use is already passed into the libsvn_client
> > > > API from the client. Pretty much all we need is a way to specify sets
> > > > of changelists more flexibly. For the main functionality, the 'commit'
> > > > subcommand would specify "select everything except changelist
> > > > 'svn:ignore-on-commit'" unless overridden. That would make the file be
> > >
> > > Does this require negative changelists? Currently changelists are
> > > 'select only members of this changelist', but you're proposing 'select except
> > > members of this changelist'.
> >
> > Yes. [...] So semantically it's not
> > new. It does need an API change of one kind or another.
>
> Fair enough.
>
> For simplicity, we can retain the status quo where no changelists are
> allowed on directories? Otherwise we'd have to decide how a negative
> changelist behaves when applied to a directory.
Yes, I'm assuming we retain the status quo.
- Julian
> (It could mean changelists are to be coupled with a depth value; but
> let's not open that can of worms unless we have to.)
Re: dump svn:hold, long live file externals?? (and discussing
recursive hold) -- was: bring on your concerns about svn:hold, please
Posted by Daniel Shahaf <da...@elego.de>.
Julian Foad wrote on Wed, Aug 24, 2011 at 13:23:53 +0100:
> On Wed, 2011-08-24 at 15:10 +0300, Daniel Shahaf wrote:
> > Julian Foad wrote on Wed, Aug 24, 2011 at 11:13:09 +0100:
> > > > > C. Michael Pilato wrote:
> > > > >> So back to what I would consider the primary deliverable of interest here:
> > > > >> avoiding one's own accidental commits. I'm leaning toward [...] A
> > > > >> special changelist honored by our libsvn_client code which does what we're
> > > > >> talking about here, shows up in 'svn status' like the others do, requires
> > > > >> very little additional infrastructure, for which state changes are not
> > > > >> versioned operations (such as they would be with the commits of the addition
> > > > >> and removal of an svn:hold property), etc.
> > >
> > > I like the sound of this, too, as the local-only part of the solution.
> > > See below for the centralized part of the solution.
> > >
> > > The set of changelists to use is already passed into the libsvn_client
> > > API from the client. Pretty much all we need is a way to specify sets
> > > of changelists more flexibly. For the main functionality, the 'commit'
> > > subcommand would specify "select everything except changelist
> > > 'svn:ignore-on-commit'" unless overridden. That would make the file be
> >
> > Does this require negative changelists? Currently changelists are
> > 'select only members of this changelist', but you're proposing 'select except
> > members of this changelist'.
>
> Yes. If that sounds like a non-trivial extension of the changelist
> semantics, it's not. Imagine we have an API to retrieve a list of all
> the changelist names and a pseudo-changelist indicator to denote "files
> that are not in any changelist". Then we could simply map that request
> into a select-multiple-changelists request. So semantically it's not
> new. It does need an API change of one kind or another.
>
Fair enough.
For simplicity, we can retain the status quo where no changelists are
allowed on directories? Otherwise we'd have to decide how a negative
changelist behaves when applied to a directory.
(It could mean changelists are to be coupled with a depth value; but
let's not open that can of worms unless we have to.)
> - Julian
>
>
Re: dump svn:hold, long live file externals?? (and discussing
recursive hold) -- was: bring on your concerns about svn:hold, please
Posted by Julian Foad <ju...@wandisco.com>.
On Wed, 2011-08-24 at 15:10 +0300, Daniel Shahaf wrote:
> Julian Foad wrote on Wed, Aug 24, 2011 at 11:13:09 +0100:
> > > > C. Michael Pilato wrote:
> > > >> So back to what I would consider the primary deliverable of interest here:
> > > >> avoiding one's own accidental commits. I'm leaning toward [...] A
> > > >> special changelist honored by our libsvn_client code which does what we're
> > > >> talking about here, shows up in 'svn status' like the others do, requires
> > > >> very little additional infrastructure, for which state changes are not
> > > >> versioned operations (such as they would be with the commits of the addition
> > > >> and removal of an svn:hold property), etc.
> >
> > I like the sound of this, too, as the local-only part of the solution.
> > See below for the centralized part of the solution.
> >
> > The set of changelists to use is already passed into the libsvn_client
> > API from the client. Pretty much all we need is a way to specify sets
> > of changelists more flexibly. For the main functionality, the 'commit'
> > subcommand would specify "select everything except changelist
> > 'svn:ignore-on-commit'" unless overridden. That would make the file be
>
> Does this require negative changelists? Currently changelists are
> 'select only members of this changelist', but you're proposing 'select except
> members of this changelist'.
Yes. If that sounds like a non-trivial extension of the changelist
semantics, it's not. Imagine we have an API to retrieve a list of all
the changelist names and a pseudo-changelist indicator to denote "files
that are not in any changelist". Then we could simply map that request
into a select-multiple-changelists request. So semantically it's not
new. It does need an API change of one kind or another.
- Julian
Re: dump svn:hold, long live file externals?? (and discussing
recursive hold) -- was: bring on your concerns about svn:hold, please
Posted by Daniel Shahaf <da...@elego.de>.
Julian Foad wrote on Wed, Aug 24, 2011 at 11:13:09 +0100:
> > > C. Michael Pilato wrote:
> > >> So back to what I would consider the primary deliverable of interest here:
> > >> avoiding one's own accidental commits. I'm leaning toward [...] A
> > >> special changelist honored by our libsvn_client code which does what we're
> > >> talking about here, shows up in 'svn status' like the others do, requires
> > >> very little additional infrastructure, for which state changes are not
> > >> versioned operations (such as they would be with the commits of the addition
> > >> and removal of an svn:hold property), etc.
>
> I like the sound of this, too, as the local-only part of the solution.
> See below for the centralized part of the solution.
>
> The set of changelists to use is already passed into the libsvn_client
> API from the client. Pretty much all we need is a way to specify sets
> of changelists more flexibly. For the main functionality, the 'commit'
> subcommand would specify "select everything except changelist
> 'svn:ignore-on-commit'" unless overridden. That would make the file be
Does this require negative changelists? Currently changelists are
'select only members of this changelist', but you're proposing 'select except
members of this changelist'.
> ignored on commit but otherwise not special (so it would show up in
> diff, etc.).
>
> And we could define a changelist 'svn:ignore-local-mods' that is ignored
> in all operations that would normally see the local mods - diff, status,
> copy, export, and even cat. Some of those operations might need to be
> extended to honour changelists if they don't already. For these
> subcommands the client might specify "all except changelists
> svn:ignore-on-commit and svn:ignore-local-mods", unless overridden, for
> example.
Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long
live file externals?? (and discussing recursive hold)
Posted by Peter Samuelson <pe...@p12n.org>.
[Stefan Sperling]
> 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.
I do not have the faith in mergemeisters you do. I think when you
merge to a file that is on hold,
1) If you have no local mods to this file, it should somehow be marked
to be exempt from the hold until it is committed. (A temporary file
property, presumably.)
2) If you do have local mods, this should be treated similar to a
textual conflict: that file can't be committed (and a recursive
commit on the directory the file is in will also fail) until it is
resolved manually in some way. The manual resolution moves the file
to state 1).
Of course, it's still possible to get into a bad situation by doing a
merge and _then_ some local mods that are not supposed to be committed.
I'd be willing to just say "so don't do that, then".
Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live
file externals?? (and discussing recursive hold)
Posted by Branko Čibej <br...@xbc.nu>.
On 24.08.2011 19:56, Mark Phippard wrote:
> On Wed, Aug 24, 2011 at 1:50 PM, Stefan Sperling <stsp@elego.de
> <ma...@elego.de>> wrote:
>
>
> 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.
>
>
>
> We could probably go round and round on this forever if we want to, right?
Maybe it's time to just drop it and concentrate on 1.7.0? This thread
has become way too long to follow, and some of the things I read are
such blathering nonsense that it doesn't bear mentioning.
I suggest everyone just steps away from this and lets it cool down for a
month or two, /then/ come up with a proper feature proposal.
-- Brane
Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live
file externals?? (and discussing recursive hold)
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Aug 24, 2011 at 1:50 PM, Stefan Sperling <st...@elego.de> wrote:
>
> 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.
>
We could probably go round and round on this forever if we want to, right?
I could just as easily say that the inexperienced developer is less likely
to be doing merges, so we do not need to optimize for them. Or I could say
that it is better that the credentials of an inexperienced developer are
committed to the repository, then having them not commit a critical
configuration change.
I think the greater point is that this issue is more complicated than it
sounded originally, which is why I also point out we do not HAVE to do
anything at all. Neels will say what is it going to hurt to have a feature
that someone does not have to use. I say it hurts us anytime we add a
feature that can create confusion and problems. Who is to say some
developer does not add this property to address their needs and then this
gets rippled out to everyone and creates problems for them that the
developer did not consider. We are the ones that are going to be left to
answer it. We really want our answer to be that you do not have to use the
feature or you can write a hook to make sure no one does? BTW, that hook
would not be trivial.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live
file externals?? (and discussing recursive hold)
Posted by Stefan Sperling <st...@elego.de>.
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.
Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live
file externals?? (and discussing recursive hold)
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Aug 24, 2011 at 1:26 PM, Stefan Sperling <st...@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 <st...@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/
Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live
file externals?? (and discussing recursive hold)
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Aug 24, 2011 at 01:12:26PM -0400, Mark Phippard wrote:
> On Wed, Aug 24, 2011 at 1:09 PM, Stefan Sperling <st...@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?
Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live
file externals?? (and discussing recursive hold)
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Aug 24, 2011 at 1:09 PM, Stefan Sperling <st...@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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live
file externals?? (and discussing recursive hold)
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Aug 24, 2011 at 12:05:00PM -0400, Mark Phippard wrote:
> There is nothing wrong with adding it and I believe I have said that. I
> have also said that I was in favor of solving the issue. All I am saying is
> that Neels has done some good work looking at what that feature means in its
> entirety and he has uncovered a number of things to consider. He happens to
> not think they are a big deal, which is fine. I am simply saying that one
> option we have is to not implement the feature until we have a better answer
> for those considerations.
OK, we're on the same page then.
I agree we need to agree on the points that are still unclear.
> 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.
Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live
file externals?? (and discussing recursive hold)
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Aug 24, 2011 at 11:44 AM, Stefan Sperling <st...@elego.de> wrote:
> On Wed, Aug 24, 2011 at 11:08:34AM -0400, Mark Phippard wrote:
> > I do not think we HAVE to do this feature. It would be nice, but it
> seems
> > to raise some challenging problems that make it less nice. Personally, I
> > just think we should not do anything, including the changelists, and
> leave
> > the recommendation of using a template.
>
> What's wrong with adding this feature when there are clearly
> people who need it? If the template solution covered all needs
> this thread wouldn't even exist.
>
There is nothing wrong with adding it and I believe I have said that. I
have also said that I was in favor of solving the issue. All I am saying is
that Neels has done some good work looking at what that feature means in its
entirety and he has uncovered a number of things to consider. He happens to
not think they are a big deal, which is fine. I am simply saying that one
option we have is to not implement the feature until we have a better answer
for those considerations. That is all I am saying. If implementing the
feature requires us to do a bunch of ugly things we do not like, then maybe
we just should not do it until we have a better answer.
We seem to be in agreement that this feature should not impact update. So
that is one problem off the table. AFAIK, there are open issues asking for
this though so we have to be in agreement we do NOT agree that this should
be done.
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 think
the changelist design gives us more options in this area, but maybe they are
too hacky.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live
file externals?? (and discussing recursive hold)
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Aug 24, 2011 at 11:08:34AM -0400, Mark Phippard wrote:
> I do not think we HAVE to do this feature. It would be nice, but it seems
> to raise some challenging problems that make it less nice. Personally, I
> just think we should not do anything, including the changelists, and leave
> the recommendation of using a template.
What's wrong with adding this feature when there are clearly
people who need it? If the template solution covered all needs
this thread wouldn't even exist.
Overall, I think this thread got hung up in details.
It seems a bit early to discuss implementation details (changelists
vs. props) when there isn't even agreement on the desired feature set.
Can we focus on that first, and then argue about how to implement it?
In http://svn.haxx.se/dev/archive-2011-08/0469.shtml Julian suggested
to create a document in style of a referance manual to document what
we really want. I think this would be a good next step if it hasn't
already happened.
My own view on this is as follows:
Ideas floating in this thread have covered behaviour of commit, update,
diff, status, merge, and repository-wide configuration of held nodes.
In my mind, the most important items are, in order:
- behaviour of commit
- repository-wide configuration of held nodes
I think we should initially aim for some minimal solution which
addresses these points and leaves room for further extension.
I don't really care how it's implemented.
Making additional subcommands do fancy things with held-back nodes is
nice but not really necessary to solve the problems this feature is
supposed to address.
Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live
file externals?? (and discussing recursive hold)
Posted by Mark Therieau <mt...@gmail.com>.
Earlier in this discussion I saw link to the FAQ which recommends using a
"template" file and a manual copy to an unversioned file (an instance of the
template). http://subversion.apache.org/faq.html#ignore-commit
I can see how that approach handles part of the
please-help-me-with-these-semi-custom-ide-project-files requests, but also
leaves some key facets up to a manual procedure, like: "you just checked out
a new working copy? don't forget to copy the template project file into the
real project file" and "hey: I just updated the template project file; time
for everyone to merge these changes into their real project files (or just
copy the template again, understanding you may get re-prompted for login
credentials, etc)"
On the other hand, the template/instance procedure neatly avoids the "oops,
I just committed my local changes back to the repository" problems, since
the instance file (the one that the IDE mucks around with) never gets
committed.
What if svn were to grow a feature that directly supported this
template/instance pattern? Possibly as a svn:template property set on the
template file (and maybe the value of svn:template being name of the
instance file?). When "svn checkout" creates the template file, it would
also copy the template file to the instance file. When "svn update" or "svn
merge" applies changes to the template file, the same changes would be
applied to the instance file (of course this is where things get a bit
tricky). Allowing local changes to exist in the instance file would, of
course, be essential, but the instance file would never be committed back to
the repository.
I'm sure there are a list of other tricky issues with this approach, but my
sense is that it may be closer to the mark than a single file that serves
two purposes. Need to set something for your local working copy? -- changes
go into the instance file and don't worry: those changes won't be committed.
Need to make changes that get committed back to the repository so that
other working copies can get them? -- those changes go into the template
file.
regards,
markt
Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long
live file externals?? (and discussing recursive hold)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Neels J Hofmeyr wrote on Wed, Aug 24, 2011 at 23:14:34 +0200:
> On 08/24/2011 05:10 PM, Mark Phippard wrote:
> > BTW, admins can also lock files in the repository to prevent accidental
> > commits of sensitive information.
>
> That's a good point, actually.
>
> If I want to add an intentional change, I steal the lock. Then lock it back
> (using a separate WC to lock the file for myself). The commit bails even
> before the modifications are sent over the wire. It's a central config.
>
Another option: use a pre-commit hook instead of locks. It does mean
the local changes will be sent to the server --- which may be a problem.
But then, you have the same problem with people (or admins) stealing the
locks...
> But: Say a template path is locked; the result is that everyone with a
> filled-in template now gets failing commits all the time. Now you need a
> convenience thing that excludes this locked file from commit locally.
>
> This still requires specific action on every single checkout to block the
> exact right files. Users will be forced to do that, they can't run a plain
> 'svn commit' and succeed.
>
> This would cover all the needs *except* that a new checkout should
> local-hold automatically without further user action.
>
> (So we can add a prop for that, ok, and then we can use that prop and don't
> need to duplicate with a changelists based implementation)
>
> ~Neels
>
Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live
file externals?? (and discussing recursive hold)
Posted by Neels J Hofmeyr <ne...@elego.de>.
On 08/24/2011 05:10 PM, Mark Phippard wrote:
> BTW, admins can also lock files in the repository to prevent accidental
> commits of sensitive information.
That's a good point, actually.
If I want to add an intentional change, I steal the lock. Then lock it back
(using a separate WC to lock the file for myself). The commit bails even
before the modifications are sent over the wire. It's a central config.
But: Say a template path is locked; the result is that everyone with a
filled-in template now gets failing commits all the time. Now you need a
convenience thing that excludes this locked file from commit locally.
This still requires specific action on every single checkout to block the
exact right files. Users will be forced to do that, they can't run a plain
'svn commit' and succeed.
This would cover all the needs *except* that a new checkout should
local-hold automatically without further user action.
(So we can add a prop for that, ok, and then we can use that prop and don't
need to duplicate with a changelists based implementation)
~Neels
Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live
file externals?? (and discussing recursive hold)
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Aug 24, 2011 at 11:08 AM, Mark Phippard <ma...@gmail.com> wrote:
> On Wed, Aug 24, 2011 at 9:32 AM, Neels J Hofmeyr <ne...@elego.de> wrote:
>
>> We'd have to change the changelists feature, beyond recognition.
>> Instead of adding a quick propget in basically one or two places,
>> we do what, overhaul changelists + plaster it with special conditions.
>>
>
> Why exactly? It seems we can declare anything on a certain named
> changelist will be ignored from commit. All we have to do is change the
> commit code to do this ignoring. IOW, we could just recreate the
> TortoiseSVN feature and nothing more. I do not see where this changes the
> changelist code.
>
> But ok, we can do that. Still, the question remains: what about Johan &
>> Co.,
>> that only have a use for ignore-on-commit if it is *centrally
>> configurable*.
>>
>
> I do not think we HAVE to do this feature. It would be nice, but it seems
> to raise some challenging problems that make it less nice. Personally, I
> just think we should not do anything, including the changelists, and leave
> the recommendation of using a template.
>
BTW, admins can also lock files in the repository to prevent accidental
commits of sensitive information.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live
file externals?? (and discussing recursive hold)
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Aug 24, 2011 at 9:32 AM, Neels J Hofmeyr <ne...@elego.de> wrote:
> We'd have to change the changelists feature, beyond recognition.
> Instead of adding a quick propget in basically one or two places,
> we do what, overhaul changelists + plaster it with special conditions.
>
Why exactly? It seems we can declare anything on a certain named changelist
will be ignored from commit. All we have to do is change the commit code to
do this ignoring. IOW, we could just recreate the TortoiseSVN feature and
nothing more. I do not see where this changes the changelist code.
But ok, we can do that. Still, the question remains: what about Johan & Co.,
> that only have a use for ignore-on-commit if it is *centrally
> configurable*.
>
I do not think we HAVE to do this feature. It would be nice, but it seems
to raise some challenging problems that make it less nice. Personally, I
just think we should not do anything, including the changelists, and leave
the recommendation of using a template.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
svn:ignore-on-commit changelist -- was: dump svn:hold, long live
file externals?? (and discussing recursive hold)
Posted by Neels J Hofmeyr <ne...@elego.de>.
I don't get why you guys are even considering changelists :)
What's the killer trait of changelists that makes this pig fly higher than a
single lightweight boolean prop? I don't see one.
I think using changelists will end up being a Dirty Hack, either
inconvenient or overly special-cased, no middle way available. It will spawn
a lot of impenetrable code, compared to just a propget.
If you're interested, read these elaborate reasons...
Changelists have been *designed* in the flipped-over wrong-way-round: they
*include*, not exclude selected items. We'd have to implement this against
its basic design. (Like using switch for externals, remember?)
Mark Phippard also talked about this kind of solution, adding a special
changelist to exclude items from commit. I've thought it through long before
proposing the svn:hold prop. My argument still holds:
We'd have to change the changelists feature, beyond recognition.
Instead of adding a quick propget in basically one or two places,
we do what, overhaul changelists + plaster it with special conditions.
But ok, we can do that. Still, the question remains: what about Johan & Co.,
that only have a use for ignore-on-commit if it is *centrally configurable*.
You say, jolly, we just add the same prop neels proposed, to manipulate
local changelists. But the prop alone is able to do the exact same thing
without even touching changelists, and in fact would achieve the same goal
with just a tiny patch of code; most of the infrastructure is already there,
entirely for free, *exactly* in the way it is needed, no flipside
special-casing required.
User says: "what, I need to set a changelist *and* a prop? o_O"
If we're *anyway* going to have a prop, which *does* provide all information
needed, then I don't see any need to complicate this. If you're so eager to
have a local-only implementation, just keep the prop out of the repos.
(I wouldn't push that beyond telling users to add a pre-commit hook, though.)
Do changelists make anything easier?
- Yes, might spare us adding an 'H' notification on 'status'.
- Changelists are kept out of version control. But svn:ignore-on-commit will
be only as long as it remains a local feature. The exact same is achieved
when the svn:hold propset is simply never committed.
- No, changelists do not solve the 'merge-held-items' situation. After
getting a merge in on an svn:ignore-on-commit'ed file, it is still not
committed along with the rest of the merge, just like with a plain prop.
Furthermore, if you do force a commit, then, guess what, the items silently
disappear from the 'ignore-on-commit' changelist! Due to their basic design!
Unless we add yet another special case there. Ugh.
Or the merger person has to remember which they were and adds them back to
the list manually. Ugh.
You could argue that the global 'svn:hold' prop is still set, and after a
merge-commit, you can automatically add those back to the changelist. I
think this is a far more complex, slow and error-prone solution than what I
proposed (just flag those files that were on hold and also received a merge,
and block the commit until the user explicitly decides what to do, using a
given cmdline option. Or by removing flags manually if desired).
- (Sure, implementing this might gain the changelists feature some useful
cmdline options, *if* we implement them in a general fashion instead of
triggering on a special name only. -- that's besides the point though.)
- (I guess that setting a prop on a node directly potentially makes faster
code than employing a look-up in a special list. But this might actually not
be true.)
-1, IMO we should totally not have an svn:ignore-on-commit changelist.
Though Tortoise devs might have liked that :)
~Neels
Re: dump svn:hold, long live file externals?? (and discussing
recursive hold) -- was: bring on your concerns about svn:hold, please
Posted by Julian Foad <ju...@wandisco.com>.
> > C. Michael Pilato wrote:
> >> Neels J Hofmeyr wrote:
> >>> Julian Foad wrote:
> >>>> Use case (2) - Eclipse folder, from issue #3028
> >>>>
> >>>> "For example we have a complete Eclipse instance in our svn
> >>>> repository and we want to ignore every change in its directory
> >>>> and below. [...]"
> >>>
> >>> That's quite a pickle. I'm not intending to make holding stuff recursive,
> >>> because then we'd have to check every commit target up into its ancestors,
> >>> possibly even checking if the *repos* has a hold set on an ancestor. Ugh.
[...]
> >>> And, my goodness, it *is* *already* possible to create a global hold on a
> >>> file using file externals. [...]
+1 on the idea of building a new feature on top of an existing
infrastructure. It reduces the cognitive load on the user. We need to
keep in mind that many users don't want or need to learn all about every
feature of Subversion. If a new feature can be described in two
sentences in terms of another feature, that's a *huge* win.
But ...
> >> Oh, dude. You're talking now about hacks based on hacks, here. It makes me
> >> hurt. :-)
... right, -0.9 on trying to use the externals code as such an
infrastructure, in its current state.
[...]
> >> So back to what I would consider the primary deliverable of interest here:
> >> avoiding one's own accidental commits. I'm leaning toward [...] A
> >> special changelist honored by our libsvn_client code which does what we're
> >> talking about here, shows up in 'svn status' like the others do, requires
> >> very little additional infrastructure, for which state changes are not
> >> versioned operations (such as they would be with the commits of the addition
> >> and removal of an svn:hold property), etc.
I like the sound of this, too, as the local-only part of the solution.
See below for the centralized part of the solution.
The set of changelists to use is already passed into the libsvn_client
API from the client. Pretty much all we need is a way to specify sets
of changelists more flexibly. For the main functionality, the 'commit'
subcommand would specify "select everything except changelist
'svn:ignore-on-commit'" unless overridden. That would make the file be
ignored on commit but otherwise not special (so it would show up in
diff, etc.).
And we could define a changelist 'svn:ignore-local-mods' that is ignored
in all operations that would normally see the local mods - diff, status,
copy, export, and even cat. Some of those operations might need to be
extended to honour changelists if they don't already. For these
subcommands the client might specify "all except changelists
svn:ignore-on-commit and svn:ignore-local-mods", unless overridden, for
example.
> Hyrum K Wright wrote:
> > [...] we'd need to support multiple
> > changelists on a single item before going this route. I wouldn't want
> > a special changelist to exclude standard ones.
I don't see a need for this file to belong to multiple changelists.
Belonging to changelist XXX says "The changes in this file are part of
feature/change/local-experiment XXX". If changes in this file are to be
ignored, then I don't see it making any sense for this file to belong to
any other changelist, unless and until the user decides that the changes
are not to be ignored.
Most of the time, the user will put the file in changelist
'svn:ignore-on-commit' and no other changes the user is making will want
to include that file. When the user wants to commit a change to that
file, he/she will either specify "--cl svn:ignore-on-commit" (with or
without other changelist(s), as appropriate) or will move this file into
a different changelist (or none) before commit and move it back into the
special changelist after commit.
Johan Corveleyn wrote:
> IMHO simply using changelists lacks the most important part of the
> feature: the ability to set/configure/annotate this centrally. [...]
Let's not dismiss changelists simply because they don't provide the
*whole* solution. This may sound like over-complication, but seriously
consider building on top of that. It's looking like changelists could
provide a decent solution for the local behaviour. On top of that, we
could provide exactly the 'svn:hold' property mechanism that Neels
already described, but instead of implementing checks for that property
directly, it could be treated as an instruction to the client to put the
file into the 'svn:ignore-on-commit' changelist (detail: if it's not
already in a changelist).
I think it's worth fleshing out a proposal using this approach.
- Julian
Re: dump svn:hold, long live file externals?? (and discussing
recursive hold) -- was: bring on your concerns about svn:hold, please
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Aug 24, 2011 at 12:03 AM, Hyrum K Wright
<hy...@wandisco.com> wrote:
> On Tue, Aug 23, 2011 at 3:07 PM, C. Michael Pilato <cm...@collab.net> wrote:
>> On 08/23/2011 11:59 AM, Neels J Hofmeyr wrote:
>>> On 08/23/2011 10:32 AM, Julian Foad wrote:
>>>> Mark (or anyone), do you recognize the use case described by Clemens
>>>> Anhuth in <http://subversion.tigris.org/issues/show_bug.cgi?id=3028>?
>>>>
>>>> Use case (2) - Eclipse folder, from issue #3028
>>>>
>>>> "For example we have a complete Eclipse instance in our svn
>>>> repository and we want to ignore every change in its directory
>>>> and below. Because Eclipse more or less at random creates and
>>>> deletes file from its own directory we have no way of knowing
>>>> which individual files may be change or deleted by starting
>>>> Eclipse. To avoid that an update creates files again that were
>>>> deleted by running Eclipse the ignore setting I am asking for
>>>> should also apply to updates. [...]"
>>>
>>> That's quite a pickle. I'm not intending to make holding stuff recursive,
>>> because then we'd have to check every commit target up into its ancestors,
>>> possibly even checking if the *repos* has a hold set on an ancestor. Ugh.
>>>
>>> So svn:hold will not support this use case. Maybe they can trick something
>>> up using externals, too....... uh........ *drop* (<-- a penny)
>>>
>>> Come to think of it... we *do* have file externals, too.
>>> And, my goodness, it *is* *already* possible to create a global hold on a
>>> file using file externals. It is just less convenient:
>>
>> Oh, dude. You're talking now about hacks based on hacks, here. It makes me
>> hurt. :-)
>>
>> I, too, have wanted a first-class solution for the "template problem". Many
>> times.
>>
>> I, too, have also (but on much less frequent occasion) wanted to prevent
>> incoming updates to a particular file.
>>
>> Now, I had always assumed the right solution for the latter of those was
>> so-called "sticky revisions" (yes, in the same sense that CVS used the term
>> "sticky" for its tags, but less automatic). You would update a file to a
>> particular revision with a special --sticky flag, and Subversion would
>> remember until further notice that you want to keep that file (or
>> directory!) at that particular revision. It's kinda like our sticky depth
>> handling today, in fact, just that we're locking stuff in time instead of in
>> space. Or something.
>>
>> Of course, I actually doubt that blocking updates is that compelling of a
>> use-case, and suspect that in terms of functionality beneficial to the
>> majority of Subversion users, it falls *well* behind the ability to avoid
>> accidentally committing one's own changes to a file (which itself falls
>> *well* behind a whole host of other, more important features, if we're being
>> honest). And when I think about where the very idea of blocking updates
>> takes us in terms of how that might affect, oh, merges and such ... well, I
>> get more than a little nauseous.
>>
>> So back to what I would consider the primary deliverable of interest here:
>> avoiding one's own accidental commits. I'm leaning toward a hostile
>> takeover of the changelist namespace (a late-breaking land grab where we say
>> "svn:<whatever>" is ours ours ours) and a changelist-based solution. A
>> special changelist honored by our libsvn_client code which does what we're
>> talking about here, shows up in 'svn status' like the others do, requires
>> very little additional infrastructure, for which state changes are not
>> versioned operations (such as they would be with the commits of the addition
>> and removal of an svn:hold property), etc.
>
> I'm not opposed to using the 'svn:' namespace for special changelists,
> particularly since changelists aren't versioned, so you're not mucking
> with data which may be in the historical record. But special
> changelists would be a nifty solution, we'd need to support multiple
> changelists on a single item before going this route. I wouldn't want
> a special changelist to exclude standard ones.
IMHO simply using changelists lacks the most important part of the
feature: the ability to set/configure/annotate this centrally. I'm not
particularly interested in a feature that forces me (as a CM) to
remind every developer that they should put the IDE project file into
their ignore-changelist after checking it out. To me that's like
having to remind them to configure the correct autoprops, or set
certain properties manually (repository-dictated autoprops, anyone?).
The question about the "template" comes up quite regularly on the
users list (not as often as questions about subtree mergeinfo or tree
conflicts, or say "authz with wildcards", but still once in a while --
and it's a FAQ after all). It's almost always in relation to IDE
project or configuration files, or makefiles, buildscripts, etc ...
Things that, in most teams, are maintained by a handful of people, but
read/used by a lot of other developers when setting up their
environment (after which the files are locally edited with
user-specific stuff).
That said, I'm not sure either that svn:hold (the property) is the
best approach (I haven't really thought through all those edge cases).
But it seems to me that it could work. OTOH, I haven't really seen
better suggestions (which keep it centrally configured).
--
Johan
Re: dump svn:hold, long live file externals?? (and discussing
recursive hold) -- was: bring on your concerns about svn:hold, please
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Tue, Aug 23, 2011 at 3:07 PM, C. Michael Pilato <cm...@collab.net> wrote:
> On 08/23/2011 11:59 AM, Neels J Hofmeyr wrote:
>> On 08/23/2011 10:32 AM, Julian Foad wrote:
>>> Mark (or anyone), do you recognize the use case described by Clemens
>>> Anhuth in <http://subversion.tigris.org/issues/show_bug.cgi?id=3028>?
>>>
>>> Use case (2) - Eclipse folder, from issue #3028
>>>
>>> "For example we have a complete Eclipse instance in our svn
>>> repository and we want to ignore every change in its directory
>>> and below. Because Eclipse more or less at random creates and
>>> deletes file from its own directory we have no way of knowing
>>> which individual files may be change or deleted by starting
>>> Eclipse. To avoid that an update creates files again that were
>>> deleted by running Eclipse the ignore setting I am asking for
>>> should also apply to updates. [...]"
>>
>> That's quite a pickle. I'm not intending to make holding stuff recursive,
>> because then we'd have to check every commit target up into its ancestors,
>> possibly even checking if the *repos* has a hold set on an ancestor. Ugh.
>>
>> So svn:hold will not support this use case. Maybe they can trick something
>> up using externals, too....... uh........ *drop* (<-- a penny)
>>
>> Come to think of it... we *do* have file externals, too.
>> And, my goodness, it *is* *already* possible to create a global hold on a
>> file using file externals. It is just less convenient:
>
> Oh, dude. You're talking now about hacks based on hacks, here. It makes me
> hurt. :-)
>
> I, too, have wanted a first-class solution for the "template problem". Many
> times.
>
> I, too, have also (but on much less frequent occasion) wanted to prevent
> incoming updates to a particular file.
>
> Now, I had always assumed the right solution for the latter of those was
> so-called "sticky revisions" (yes, in the same sense that CVS used the term
> "sticky" for its tags, but less automatic). You would update a file to a
> particular revision with a special --sticky flag, and Subversion would
> remember until further notice that you want to keep that file (or
> directory!) at that particular revision. It's kinda like our sticky depth
> handling today, in fact, just that we're locking stuff in time instead of in
> space. Or something.
>
> Of course, I actually doubt that blocking updates is that compelling of a
> use-case, and suspect that in terms of functionality beneficial to the
> majority of Subversion users, it falls *well* behind the ability to avoid
> accidentally committing one's own changes to a file (which itself falls
> *well* behind a whole host of other, more important features, if we're being
> honest). And when I think about where the very idea of blocking updates
> takes us in terms of how that might affect, oh, merges and such ... well, I
> get more than a little nauseous.
>
> So back to what I would consider the primary deliverable of interest here:
> avoiding one's own accidental commits. I'm leaning toward a hostile
> takeover of the changelist namespace (a late-breaking land grab where we say
> "svn:<whatever>" is ours ours ours) and a changelist-based solution. A
> special changelist honored by our libsvn_client code which does what we're
> talking about here, shows up in 'svn status' like the others do, requires
> very little additional infrastructure, for which state changes are not
> versioned operations (such as they would be with the commits of the addition
> and removal of an svn:hold property), etc.
I'm not opposed to using the 'svn:' namespace for special changelists,
particularly since changelists aren't versioned, so you're not mucking
with data which may be in the historical record. But special
changelists would be a nifty solution, we'd need to support multiple
changelists on a single item before going this route. I wouldn't want
a special changelist to exclude standard ones.
-Hyrum
> But these are just my leanings. I'm not deep enough into the consideration
> of all things relevant and tangential to formulate a clearer and more
> influential proposal.
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
>
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: dump svn:hold, long live file externals?? (and discussing recursive
hold) -- was: bring on your concerns about svn:hold, please
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 08/23/2011 11:59 AM, Neels J Hofmeyr wrote:
> On 08/23/2011 10:32 AM, Julian Foad wrote:
>> Mark (or anyone), do you recognize the use case described by Clemens
>> Anhuth in <http://subversion.tigris.org/issues/show_bug.cgi?id=3028>?
>>
>> Use case (2) - Eclipse folder, from issue #3028
>>
>> "For example we have a complete Eclipse instance in our svn
>> repository and we want to ignore every change in its directory
>> and below. Because Eclipse more or less at random creates and
>> deletes file from its own directory we have no way of knowing
>> which individual files may be change or deleted by starting
>> Eclipse. To avoid that an update creates files again that were
>> deleted by running Eclipse the ignore setting I am asking for
>> should also apply to updates. [...]"
>
> That's quite a pickle. I'm not intending to make holding stuff recursive,
> because then we'd have to check every commit target up into its ancestors,
> possibly even checking if the *repos* has a hold set on an ancestor. Ugh.
>
> So svn:hold will not support this use case. Maybe they can trick something
> up using externals, too....... uh........ *drop* (<-- a penny)
>
> Come to think of it... we *do* have file externals, too.
> And, my goodness, it *is* *already* possible to create a global hold on a
> file using file externals. It is just less convenient:
Oh, dude. You're talking now about hacks based on hacks, here. It makes me
hurt. :-)
I, too, have wanted a first-class solution for the "template problem". Many
times.
I, too, have also (but on much less frequent occasion) wanted to prevent
incoming updates to a particular file.
Now, I had always assumed the right solution for the latter of those was
so-called "sticky revisions" (yes, in the same sense that CVS used the term
"sticky" for its tags, but less automatic). You would update a file to a
particular revision with a special --sticky flag, and Subversion would
remember until further notice that you want to keep that file (or
directory!) at that particular revision. It's kinda like our sticky depth
handling today, in fact, just that we're locking stuff in time instead of in
space. Or something.
Of course, I actually doubt that blocking updates is that compelling of a
use-case, and suspect that in terms of functionality beneficial to the
majority of Subversion users, it falls *well* behind the ability to avoid
accidentally committing one's own changes to a file (which itself falls
*well* behind a whole host of other, more important features, if we're being
honest). And when I think about where the very idea of blocking updates
takes us in terms of how that might affect, oh, merges and such ... well, I
get more than a little nauseous.
So back to what I would consider the primary deliverable of interest here:
avoiding one's own accidental commits. I'm leaning toward a hostile
takeover of the changelist namespace (a late-breaking land grab where we say
"svn:<whatever>" is ours ours ours) and a changelist-based solution. A
special changelist honored by our libsvn_client code which does what we're
talking about here, shows up in 'svn status' like the others do, requires
very little additional infrastructure, for which state changes are not
versioned operations (such as they would be with the commits of the addition
and removal of an svn:hold property), etc.
But these are just my leanings. I'm not deep enough into the consideration
of all things relevant and tangential to formulate a clearer and more
influential proposal.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
dump svn:hold, long live file externals?? (and discussing recursive
hold) -- was: bring on your concerns about svn:hold, please
Posted by Neels J Hofmeyr <ne...@elego.de>.
On 08/23/2011 10:32 AM, Julian Foad wrote:
> Mark (or anyone), do you recognize the use case described by Clemens
> Anhuth in <http://subversion.tigris.org/issues/show_bug.cgi?id=3028>?
>
> Use case (2) - Eclipse folder, from issue #3028
>
> "For example we have a complete Eclipse instance in our svn
> repository and we want to ignore every change in its directory
> and below. Because Eclipse more or less at random creates and
> deletes file from its own directory we have no way of knowing
> which individual files may be change or deleted by starting
> Eclipse. To avoid that an update creates files again that were
> deleted by running Eclipse the ignore setting I am asking for
> should also apply to updates. [...]"
That's quite a pickle. I'm not intending to make holding stuff recursive,
because then we'd have to check every commit target up into its ancestors,
possibly even checking if the *repos* has a hold set on an ancestor. Ugh.
So svn:hold will not support this use case. Maybe they can trick something
up using externals, too....... uh........ *drop* (<-- a penny)
Come to think of it... we *do* have file externals, too.
And, my goodness, it *is* *already* possible to create a global hold on a
file using file externals. It is just less convenient:
[[[
echo templ > templ
echo foo > foo
svn add templ foo
svn ci -mm
svn up
svn rm templ
svn ci -mm
svn up
svn ps svn:externals "^/templ@1 templ" .
svn ci -mm
svn up
svn st
echo secret >> templ
echo mod >> foo
svn st
svn ci -mm
#Sending foo
#Sending templ
#svn: Commit failed (details follow):
#svn: File 'templ' is out of date
#svn: File not found: transaction '3-3', path '/templ'
]]]
Creating an intended modification of the template would entail resurrecting
the templ file somewhere, and then updating the external's peg to that.
(could also be in e.g. ^/templates instead of from deleted history).
But now, all naive commits are blocked, because the file external is
perpetually out-of-date. Users will ask for --exclude <glob> AKA
svn:ignore-on-versioned-files AKA svn:hold all over again.
BUT, when we simply don't by default let 'commit' "recurse into"
file-externals that have a peg revision, well, frankly, there might be no
need for svn:hold at all. (Kinda hard to admit that, but there you go)
Have I actually leveraged svn:hold out of svn with this? :) I still think
svn:hold is a better, less confusing, more convenient solution. What do you
think, tip towards being downwright conservative or being convenient?
Downsides to using file externals as a means to hold:
- There is no convenient way to hold locally-only, or the problem
perpetuates, because now you want only one svn:externals entry
(and possibly a local-delete) to be kept out of all your commits
-- an insane minefield.
Better for local-only hold: add an --exclude <glob> option to
commit, BUT it would have to be set explicitly on every commit
in all the right WCs. Per-user ~/subversion/config for this may not
be specific enough to conveniently affect only the right paths.
- It is harder to create an intended modification on the template.
(resurrect&mod the file, then update the externals definition.
But may also be done on a dedicated branch like ^/templates)
- It may be confusing to average users. Well, only so much.
How does the merge situation resolve when using file externals?
[I'll run trials and be back with another mail on merge]
Well, at least now I'm definitely against svn:hold acting recursively on
dirs. Users that want this can use above approach with dir externals
(showcased below), where commits don't even recurse into the external, so it
is fairly convenient. The only downside is that only a global setup for this
is really useful (or have to keep svn:externals propset out of commit).
[[[
mkdir tdir
echo templ > tdir/templ
echo foo > foo
svn add tdir foo
svn ci -mm
svn up
svn rm tdir
svn ci -mm
svn up
svn ps svn:externals "^/tdir@1 tdir" .
svn ci -mm
svn up
svn st
echo secret >> tdir/templ
echo mod >> foo
svn st
svn ci -mm
#Sending foo
#Transmitting file data .
#Committed revision 4.
# yay! 'templ' was not sent!
]]]
~Neels
Re: bring on your concerns about svn:hold, please
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Aug 23, 2011 at 4:32 AM, Julian Foad <ju...@wandisco.com>wrote:
> Mark Phippard wrote:
> > [...] You like to talk about the IDE use case, so let's talk about
> > it. That is where I am coming from on this too. In Subclipse, [...]
>
> Mark (or anyone), do you recognize the use case described by Clemens
> Anhuth in <http://subversion.tigris.org/issues/show_bug.cgi?id=3028>?
>
> Use case (2) - Eclipse folder, from issue #3028
>
> "For example we have a complete Eclipse instance in our svn
> repository and we want to ignore every change in its directory
> and below. Because Eclipse more or less at random creates and
> deletes file from its own directory we have no way of knowing
> which individual files may be change or deleted by starting
> Eclipse. To avoid that an update creates files again that were
> deleted by running Eclipse the ignore setting I am asking for
> should also apply to updates. [...]"
>
> Is this use case important? Can such a case be adequately handled in
> practice by what we've been discussing, despite what Clemens claims
> about the need for recursive effect and avoiding the re-creation of
> deleted files?
>
>
I have never heard anyone ask for this, so while I think it is probably a
valid use case, I cannot imagine it is common enough to be important. I
also have to imagine in most cases like this the Eclipse IDE files would be
stored in the tree in such a way that it was relatively easy to simply
commit from another part of the tree to ignore it.
In terms of how we could handle the use-case, we would have to allow
svn:hold to be set on folders and then have that mean that commit does not
harvest-committables from children of that folder. Do I think we should do
this ... probably not.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: bring on your concerns about svn:hold, please
Posted by Julian Foad <ju...@wandisco.com>.
Mark Phippard wrote:
> [...] You like to talk about the IDE use case, so let's talk about
> it. That is where I am coming from on this too. In Subclipse, [...]
Mark (or anyone), do you recognize the use case described by Clemens
Anhuth in <http://subversion.tigris.org/issues/show_bug.cgi?id=3028>?
Use case (2) - Eclipse folder, from issue #3028
"For example we have a complete Eclipse instance in our svn
repository and we want to ignore every change in its directory
and below. Because Eclipse more or less at random creates and
deletes file from its own directory we have no way of knowing
which individual files may be change or deleted by starting
Eclipse. To avoid that an update creates files again that were
deleted by running Eclipse the ignore setting I am asking for
should also apply to updates. [...]"
Is this use case important? Can such a case be adequately handled in
practice by what we've been discussing, despite what Clemens claims
about the need for recursive effect and avoiding the re-creation of
deleted files?
- Julian
Re: bring on your concerns about svn:hold, please
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Aug 22, 2011 at 7:19 PM, Neels J Hofmeyr <ne...@elego.de> wrote:
> > When you do a merge, we could automatically remove a file from the
> > ignore changelist so that it would be committed by default and not
> > require the user to add a special option to their commit.
>
> My preceding mail elaborated on this point; the local modifications may be
> considered secret, so svn should not fully-automatically commit held stuff,
> but should instead complain to the user.
>
> > Right now, I think the negatives far exceed the positives.
> > I think this feature could actually wind up being very
> > confusing to users.
>
> I don't see it that way at all. I don't see how negatives that don't ever
> appear until you even use the feature can outweigh any positives you can
> get
> if you choose to use the feature. I have proposed numerous solutions to all
> negatives. I'm thinking: whether to use svn:hold in the repos is up to
> project management. Users can still use it locally. It's always a choice.
>
Just because you do not have to use the features does not mean that adding
them cannot lead to problems and confusions. You like to talk about the IDE
use case, so let's talk about it. That is where I am coming from on this
too. In Subclipse, when someone does commit we load a dialog with all of
the modified files, do we show modified files with this property? If we do,
and the API does not commit the file that is going to confuse users. This
even assumes the Status API has some value that let's us know the modified
file has this property. If we have to do secondary API calls to get this
information, I'll be pissed as both a developer and user.
Most likely we have to add new UI to our commit dialog that lets you toggle
whether or not to show these files. Maybe we can implement it such that
this UI only shows up if we detect you have some of these files, but if not
then all users have to pay the price of extra "stuff" in the UI.
In Subclipse we also have a Synchronize view which visualizes local and
remote changes. This is another place where we will have to account for
this.
I am not saying the feature has no value, or even that your design approach
is bad. I am just saying the issue is more complicated than I originally
thought and I have been thinking out loud on the problems I see with it.
I just need a basic go-ahead that the users' call for such a feature
> should/is allowed to be answered. How minimal it will be is totally up for
> discussion. I can offer more patches, and you can decline them.
>
> At this point, I want hard fact & proof if you're going to say "no".
>
Speaking for myself, I am not threatening a veto or anything. I am just
expressing my concerns so that we can talk through and possibly improve the
design.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: bring on your concerns about svn:hold, please
Posted by Neels J Hofmeyr <ne...@elego.de>.
Thanks for talking some shop :)
I'm combining my replies to a few sub-threads in one.
At the bottom, I try to reduce the volume of this thread, so consider
skipping to just above where it says "neels: +1" near the bottom.
Mark Phippard wrote:
> When you do a merge, we could automatically remove a file from the
> ignore changelist so that it would be committed by default and not
> require the user to add a special option to their commit.
My preceding mail elaborated on this point; the local modifications may be
considered secret, so svn should not fully-automatically commit held stuff,
but should instead complain to the user.
> Right now, I think the negatives far exceed the positives.
> I think this feature could actually wind up being very
> confusing to users.
I don't see it that way at all. I don't see how negatives that don't ever
appear until you even use the feature can outweigh any positives you can get
if you choose to use the feature. I have proposed numerous solutions to all
negatives. I'm thinking: whether to use svn:hold in the repos is up to
project management. Users can still use it locally. It's always a choice.
Julian Foad wrote:
> WC-DB columns are taboo in this thread :-)
I was just saying, if people think it's too slow, there is room in that
direction. I wasn't anywhere near actually implementing that :)
I like your use case description:
[[[
(1) An IDE configuration file (for example) is stored in the WC and it
is convenient for new checkouts to contain this file. The IDE typically
makes local changes to this file which would not be appropriate for
other users to see, such as a password or the directory to use for
temporary files. We don't want to commit these changes in a normal
commit. Occasionally, one of the developers wants to commit an
intentional modification to the config file. To do so, he/she will
revert the changes in that file that are specific to his/her username or
workstation or whatever, and carefully make and commit the desired
change. Other users expect to get any such changes when they do a
regular Subversion update. The file is assumed to be mergeable (text).
]]]
I would add that it can be useful on binary files, too.
And I need to add that the intentionally made commits on that file must
still be merged normally, and thus mergers have to take care if such changes
are part of a merge. During a merge, a user would have to discard any
non-public entries from the held-back file, like described in your use case.
(we can plaster users with warnings if they hit this case.)
> And what's this about local-diff? You intend to ignore the whole
> file that is 'held'? Or do you intend to print diffs of the parts
> that were merged [...]
I use 'svn diff' to check the local modifications that are going to be
committed. Right?? How is it obscure to omit local modifications on a
held-back file? (All mods that are already committed *are* shown.)
I would find it confusing to see changes in the diff that won't be
committed. If *all* changes are desired, as is the case during any merge
situation, again, just use --do-not-hold.
But fine, we can not affect local diff, if it is generally preferred.
> Neels wrote:
> > (With wc-copies, we should probably not copy local mods though, and
> > a diff of local mods should omit held-back stuff. But that's *all*.)
> Why that? That's a significant extra semantic change.
The only reason why I'm proposing this is to provide one more hurdle for
local secrets to leak into the repos. I am particularly arguing about a
wc-to-url copy, which would put the mods straight into a revision.
I also discussed that in notes/hold.
But, yes, we can leave that copy stuff for later, no worries at all.
> the word 'template'
This thread, linked from issue #2858, mentions an 'svn:template' prop
(roughly similar to my 'svn:hold' proposal)
http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=129599
Greg Stein wrote:
> ... but svn:hold? That alters the very operation of a
> version-controlled file. Now, all of a sudden... it does not
> participate in a commit. If somebody set the value *locally*, then I
> say "fine. they did it. they should know". But this thing can go into
> the repository, and then just appear in my working copy. And out of
> nowhere, my files don't commit like they should.
I think you're exaggerating. I agree with danielsh that there is no
essential difference to svn:ignore.
Each site can decide: do we allow 'svn:hold' props to be committed? If not,
pre-commit hook, done. Where is there a *real* problem here?
Committing a replace of a file can have much worse implications that are
much harder to spot ('evil twins'), yet you don't propose to purge replace
functionality from Subversion. You (probably) say: pre-commit hook, done.
> And now you're saying that it affects more than commit. Diffs? Copies?
Not necessarily. I just see that it makes a lot of sense to affect *local
changes* on held-back files during those two commands, considering wc-to-url
copies.
> If you limit it to *just* commits, and if the generated log message
> would say something like, "The following files are being held from
> commit:\nH some/path/foo \nH other/path/bar\n", then I'd be more
> supportive. When somebody goes to commit, then it is very clear these
> files are not participating. (and yes, showing 'H' in status is a good
> thing, with the understanding it means "modified, but being held"; the
> file should not show at all, if unmodified)
I agree with all of that! We *can* limit it to *just* commits. I *want* it
to print exactly that info, as you just said it. Adding hints to the
generated log message is a very good idea.
> I think 'svn diff' should continue to show the local modifications.
> And it should be copied just like any other file. And that may mean
> copying with the local mods. When committing that copy, a copy will be
> performed on the server, but the local mods will not reach the server
> due to the svn:hold.
My guess is that after a while, people will knock on the door asking why
they saw local mods in the diff that didn't get committed. I already coded
the part that omits *only* local mods from diffs on held-back files, on the
'hold' branch, but I can easily revert that again. No worries, *if* you want
that. Same goes with a wc-to-url copy: people will say "but those local mods
were *on hold*! Now my SQL password is in the history again and we have to
touch all the servers with a new password, right now, *again*! Admins will
be home late tonight, and tomorrow they *will* kill me!!"
The copy part isn't even implemented yet, so I can easily refrain from that,
leaving the kill to admins around the world ;)
Daniel Shahaf wrote:
> Random thought: We could have 'svn update' output warn when such special
> properties (svn:ignore, svn:add, svn:server-dictated-hook, svn:repository-
> dictated-config) are added by an update.
I agree with showing a warning during update:
- for adding 'svn:hold' to a locally modded file (maybe even *any* file)
- removing 'svn:hold' from local mods (maybe even unmodified files too)
- for any svn:ignore change, too, nice idea, but is a bit OT here.
But, Daniel, what does 'svn:add' do? ;) nm...
Stefan Küng wrote:
> That feature is only to prevent commits. Users use this to keep
> their local modifications from getting into the repository.
> It's basically used only for config files they need to modify
> to suit their local paths or setups.
> So no merging.
What does that mean, no merging. If someone changes the config template on
purpose, and that change is committed and is later part of a merge, that
merge should happen and be committed, too.
But I think this will probably not happen a lot. If people decided a given
file is a template, it will hardly ever see any changes committed to it.
> And they still get updates if the file gets modified in the repository -
> that's what they still want!
Thanks for that statement :)
I think we can all agree now that 'svn:hold' should not need to restrict
'update' in any way.
(I just want it to show a warning when an 'svn:hold' was deleted away from
local mods, s.a.)
<steam-valve>
So! If they want it, and if it's easy to implement, and if performance
impact is low/unnoticeable/workaroundable, and if it's *optional* (usable
local-only; and even cheaply, *optionally*, globally usable, for free, iff
project management and pre-commit permit; we could even ship with svn:hold
prohibiting code in the pre-commit template), and if Tortoise already does
something almost similar...
Then why the heck not?
What's this growing discussion actually *about*?
Auras and bikesheds?
I've really put a lot of thought in it, and there aren't any prohibitive
problems. Merge is a nut to crack but totally crackable by very simple means
(warnings for starters, and, if deemed necessary by us/you, some flag to
affect the commit after a merge touched a held-back file).
I wish more users read this list.
</steam-valve>
Sorry, had to blow off some steam ;)
Whoa, let's try to get this thread to shrink back a little.
How about just discussing "svn:hold affects *only* commit" for a start.
So if 'svn:hold' *only* affects commit; Would I eventually be allowed to
code this into trunk?
neels: +1
Such a patch is surprisingly simple, see r1159240 (for the basic approach;
naming was tweaked later).
Once that's there, an appropriate status should be printed and appropriate
warnings produced where it makes sense, as discussed above. That can follow
in the course up to 1.8. I can do these, if no-one else wants to help.
And I can stay on the branch for a while to come, too. Would just be more
convenient on trunk, cuts out all that merging.
I just need a basic go-ahead that the users' call for such a feature
should/is allowed to be answered. How minimal it will be is totally up for
discussion. I can offer more patches, and you can decline them.
At this point, I want hard fact & proof if you're going to say "no".
~Neels
Re: bring on your concerns about svn:hold, please
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Aug 22, 2011 at 1:17 PM, Julian Foad <ju...@wandisco.com>wrote:
> I haven't heard of this issue being referred to with the word
> 'template'. I've heard requests for log message templates, and I've
> heard requests for 'views' that map a WC to a set of repos paths which
> might sometimes be called 'templates'.
>
See: http://subversion.apache.org/faq.html#ignore-commit
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: bring on your concerns about svn:hold, please
Posted by Julian Foad <ju...@wandisco.com>.
Can we try to concentrate on the behaviour required, and not yet concern
ourselves with the implementation technology other than as a tool for
describing the behaviour? WC-DB columns are taboo in this thread :-)
As far as I know we are all talking about the following use case:
(1) An IDE configuration file (for example) is stored in the WC and it
is convenient for new checkouts to contain this file. The IDE typically
makes local changes to this file which would not be appropriate for
other users to see, such as a password or the directory to use for
temporary files. We don't want to commit these changes in a normal
commit. Occasionally, one of the developers wants to commit an
intentional modification to the config file. To do so, he/she will
revert the changes in that file that are specific to his/her username or
workstation or whatever, and carefully make and commit the desired
change. Other users expect to get any such changes when they do a
regular Subversion update. The file is assumed to be mergeable (text).
If anyone thinks there are other use cases, please speak up.
Neels wrote:
> - I strongly agree that we do *not* hold updates or anything else, except
> commit.
Sounds reasonable, based on the use case (1).
> (With wc-copies, we should probably not copy local mods though, and
> a diff of local mods should omit held-back stuff. But that's *all*.)
Why that? That's a significant extra semantic change.
[... and, later ...]
> it would affect:
>
> commit,
> local-diff,
> wc-to-* copy,
> merge (print warning to add --do-not-hold to the next commit
> OR set flag),
> update/switch (print warning if prop gets removed,
> iff there are local mods aka secrets).
And what's this about local-diff? You intend to ignore the whole file
that is 'held'? Or do you intend to print diffs of the parts that were
merged but not diffs of the parts of it that were changed by the IDE?
(I'm joking, but only just.)
[...]
> - #svn, the issue tracker (and probably the users@ list too though I haven't
> checked) perpetually bring up this "template" problem. Tortoise has a per-WC
> solution; we just have dumb workarounds, really.
Issue numbers?
I haven't heard of this issue being referred to with the word
'template'. I've heard requests for log message templates, and I've
heard requests for 'views' that map a WC to a set of repos paths which
might sometimes be called 'templates'.
- Julian
Re: bring on your concerns about svn:hold, please
Posted by Stefan Küng <to...@gmail.com>.
On 22.08.2011 19:23, Mark Phippard wrote:
> On Mon, Aug 22, 2011 at 1:20 PM, Stefan Küng <tortoisesvn@gmail.com
> <ma...@gmail.com>> wrote:
>
> On 22.08.2011 18:51, Neels J Hofmeyr wrote:
>
> Since TortoiseSVN has had this feature for a long time, it would
> be interesting to know what kind of edge cases people have
> raised with the
> feature. Has anyone asked that these files not be updated
> or merged?
>
>
> I've asked, but only on this list... good point, I should ask
> tortoise devs
> directly. (But their changelist is called "ignore-on-commit", so
> it's pretty
> clear what it does, I guess.)
>
>
> Apart from a few bugs in our code, we haven't had any issues with
> that special changelist. At least users haven't reported any.
> The bugs we had were related to having files in that changelist
> initially checked for commit when the commit dialog came up.
>
>
> So no one has come around asking you to block updates to this file when
> they run update? What about merge? Any problems with merged changes
> not being included in the commit? That seems like a potentially huge
> problem to me.
That feature is only to prevent commits. Users use this to keep their
local modifications from getting into the repository. It's basically
used only for config files they need to modify to suit their local paths
or setups.
So no merging.
And they still get updates if the file gets modified in the repository -
that's what they still want!
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: bring on your concerns about svn:hold, please
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Aug 22, 2011 at 1:20 PM, Stefan Küng <to...@gmail.com> wrote:
> On 22.08.2011 18:51, Neels J Hofmeyr wrote:
>
> Since TortoiseSVN has had this feature for a long time, it would
>>> be interesting to know what kind of edge cases people have raised with
>>> the
>>> feature. Has anyone asked that these files not be updated or merged?
>>>
>>
>> I've asked, but only on this list... good point, I should ask tortoise
>> devs
>> directly. (But their changelist is called "ignore-on-commit", so it's
>> pretty
>> clear what it does, I guess.)
>>
>
> Apart from a few bugs in our code, we haven't had any issues with that
> special changelist. At least users haven't reported any.
> The bugs we had were related to having files in that changelist initially
> checked for commit when the commit dialog came up.
>
So no one has come around asking you to block updates to this file when they
run update? What about merge? Any problems with merged changes not being
included in the commit? That seems like a potentially huge problem to me.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: bring on your concerns about svn:hold, please
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/8/22 Stefan Küng <to...@gmail.com>:
> On 22.08.2011 18:51, Neels J Hofmeyr wrote:
>
>>> Since TortoiseSVN has had this feature for a long time, it would
>>> be interesting to know what kind of edge cases people have raised with
>>> the
>>> feature. Has anyone asked that these files not be updated or merged?
>>
>> I've asked, but only on this list... good point, I should ask tortoise
>> devs
>> directly. (But their changelist is called "ignore-on-commit", so it's
>> pretty
>> clear what it does, I guess.)
>
> Apart from a few bugs in our code, we haven't had any issues with that
> special changelist. At least users haven't reported any.
> The bugs we had were related to having files in that changelist initially
> checked for commit when the commit dialog came up.
>
> Stefan
>
One thing I miss with "ignore-on-commit" is that I actually want all
changelists to behave this way: to be unselected by default.
I usually use change lists to mark some work in progress. When
committing I have to start with unselecting all, then I usually select
the non-in-changelist items (they are grouped in TortoiseSVN as well)
or the changelist I want to commit.
If anyone wants to keep the current behaviour where only
"ignore-on-commit" is special, it could be customizable, e.g.
configure it to ignore all "ignore-*" or "WIP-*" lists, or "*".
Best regards,
Konstantin Kolinko
Re: bring on your concerns about svn:hold, please
Posted by Stefan Küng <to...@gmail.com>.
On 22.08.2011 18:51, Neels J Hofmeyr wrote:
>> Since TortoiseSVN has had this feature for a long time, it would
>> be interesting to know what kind of edge cases people have raised with the
>> feature. Has anyone asked that these files not be updated or merged?
>
> I've asked, but only on this list... good point, I should ask tortoise devs
> directly. (But their changelist is called "ignore-on-commit", so it's pretty
> clear what it does, I guess.)
Apart from a few bugs in our code, we haven't had any issues with that
special changelist. At least users haven't reported any.
The bugs we had were related to having files in that changelist
initially checked for commit when the commit dialog came up.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: bring on your concerns about svn:hold, please
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Aug 22, 2011 at 12:51 PM, Neels J Hofmeyr <ne...@elego.de> wrote:
> On 08/22/2011 04:45 PM, Mark Phippard wrote:
> > On Mon, Aug 22, 2011 at 10:32 AM, Neels J Hofmeyr <neels@elego.de
> > <ma...@elego.de>> wrote:
> >
> > Greg/anyone, do you have any more arguments against svn:hold except
> "people
> > will trip over a prop they read the documentation of and set up
> themselves
> > before it had any effect" -- because I don't think that's a real
> problem.
> > They would have tripped over 'svn:ignore', 'svn:externals' and
> > 'svn:keywords' long before tripping over 'svn:hold'. BTW, my
> intention is to
> > clearly mark held-back local mods in 'svn status' (e.g. 'H');
> particularly
> > important for merge situations.
> >
> > In my vision, 'svn:hold' would be the exception, in the scale of one
> > build.conf type of file per huge project tree. But that's up to the
> users.
> > Which is exactly the point!
> >
> > (See notes/hold for more points.)
> >
> >
> >
> > I really do not know where I stand on this. If you had asked me before
> you
> > started if it would be good to have a feature where certain local files
> > could be ignored by commit I would have said Yes. Now that you have
> started
> > working on it, and some more thought has gone into it I am less sure. I
> do
> > worry about the implications of a feature like this in terms of what the
> > behavior should be on other commands.
> >
> > Maybe a different implementation could make a difference? Just thinking
> out
> > loud ....
> >
> > What if SVN had a feature like TortoiseSVN where any file in a
> specifically
> > named changelist was automatically ignored on commit unless that specific
> > changelist is named ($ svn ci -cl ignored-files ) We could probably make
> > commands like status and diff automatically ignore this changelist too.
>
> Hi Mark,
>
> you first express concerns about implications on other commands, and then
> you propose the exact same feature and implications using changelists? Come
> on :)
>
> >
> > Perhaps we could then go a step farther with this feature by
> automatically
> > adding files with a special property like svn:hold to this changelist
> when
> > they are checked out?
>
> I thought about this too, actually, and came to this conclusion: it just
> inflates the whole implementation. Nothing more. The exact same thing can
> be
> achieved with *just* a property, without having to "rape" changelists: the
> changes to changelists would be: introduce special treatment of changelists
> that have a specific name (-1). Introduce reversable changelists (+1) but
> only do it implicitly, if it has one certain name (-1). *After* you did
> this, you put into life a property (where we already have a reserved
> namespace and long history for storing svn-internals), and instead of
> querying the prop directly, you have changelists inserted in the chain. I'm
> -1 to that.
>
I think there is a difference. By using a combination of svn:hold and
changelists the tool can do work for the user. Merge is the best example
(it might be the only example). When you do a merge, we could automatically
remove a file from the ignore changelist so that it would be committed by
default and not require the user to add a special option to their commit.
Commit could then put the file back on to the ignore list.
I do not think we have to use changelists to accomplish this. I was just
using that as an example. Using changelists does have a benefit that it
already has a lot of UI.
Wow, I didn't think I'd have to argue this much :)
> I still don't see how 'svn:hold' is problematic to include in 1.8.
> More cons?
>
I would not have expected this either. But I have to say that I am not
convinced that the benefits of this feature outweigh the negatives. Right
now, I think the negatives far exceed the positives. I think this feature
could actually wind up being very confusing to users.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: bring on your concerns about svn:hold, please
Posted by Neels J Hofmeyr <ne...@elego.de>.
On 08/22/2011 04:45 PM, Mark Phippard wrote:
> On Mon, Aug 22, 2011 at 10:32 AM, Neels J Hofmeyr <neels@elego.de
> <ma...@elego.de>> wrote:
>
> Greg/anyone, do you have any more arguments against svn:hold except "people
> will trip over a prop they read the documentation of and set up themselves
> before it had any effect" -- because I don't think that's a real problem.
> They would have tripped over 'svn:ignore', 'svn:externals' and
> 'svn:keywords' long before tripping over 'svn:hold'. BTW, my intention is to
> clearly mark held-back local mods in 'svn status' (e.g. 'H'); particularly
> important for merge situations.
>
> In my vision, 'svn:hold' would be the exception, in the scale of one
> build.conf type of file per huge project tree. But that's up to the users.
> Which is exactly the point!
>
> (See notes/hold for more points.)
>
>
>
> I really do not know where I stand on this. If you had asked me before you
> started if it would be good to have a feature where certain local files
> could be ignored by commit I would have said Yes. Now that you have started
> working on it, and some more thought has gone into it I am less sure. I do
> worry about the implications of a feature like this in terms of what the
> behavior should be on other commands.
>
> Maybe a different implementation could make a difference? Just thinking out
> loud ....
>
> What if SVN had a feature like TortoiseSVN where any file in a specifically
> named changelist was automatically ignored on commit unless that specific
> changelist is named ($ svn ci -cl ignored-files ) We could probably make
> commands like status and diff automatically ignore this changelist too.
Hi Mark,
you first express concerns about implications on other commands, and then
you propose the exact same feature and implications using changelists? Come
on :)
>
> Perhaps we could then go a step farther with this feature by automatically
> adding files with a special property like svn:hold to this changelist when
> they are checked out?
I thought about this too, actually, and came to this conclusion: it just
inflates the whole implementation. Nothing more. The exact same thing can be
achieved with *just* a property, without having to "rape" changelists: the
changes to changelists would be: introduce special treatment of changelists
that have a specific name (-1). Introduce reversable changelists (+1) but
only do it implicitly, if it has one certain name (-1). *After* you did
this, you put into life a property (where we already have a reserved
namespace and long history for storing svn-internals), and instead of
querying the prop directly, you have changelists inserted in the chain. I'm
-1 to that.
Also realize: having an implicit negative changelist is basically the same
as having the svn:hold property set locally. It doesn't get committed
(unless you force it) so it's like a WC-specific config, like a negative
changelist. But you get the option to easily commit and send it to other
users almost for free, just add the --do-not-hold option (an option that
should anyway exist, even for a negative changelist).
If I were to decide, svn:hold would act by default as soon as it is present,
but I'd also be fine to force users to pass a --do-hold option or having to
set a ~/.subversion/conf item before their clients heed svn:hold props.
*Then* it would be *exactly* what you just proposed, just a lot cleaner to
implement (not introducing changelists exceptions), with the option of
allowing that prop to go through to other WCs directly.
>
> Maybe if svn merge updates a file with this property it removes it from the
> changelist so that it will be in the list of files to commit? svn commit
> could add the file back to the changelist, just as a commit on a locked file
> puts the read-only attribute back on the file?
That sounds overly complicated to me.
How do you remember which of the files 'svn commit' should add back to the
changelist? I'd rather have an explicit NODES-table column for that,
changelists or no. FWIW, 'merge' could actually add a temporary 'svn:merged'
prop next to the 'svn:hold' prop to warn 'svn commit'.
And for the use case where people want to prevent secrets from being
committed, this could be very dangerous. Switching off blocking behaviour
should thus have to be done explicitly by the user, to acknowledge that no
secrets exist in the current local modifications. That's why I'd only go as
far as commit-after-a-merge refusing to go ahead until
--do-not-hold/--do-hold (or similar) is passed explicitly.
>
> An approach like this might be more complicated to implement but it avoids
> adding new options,
I disagree with not needing new options, and I don't think that new options
are a bad thing, either ;)
And I agree that it's more complicated :)
> and I *think* it makes the behavior on other commands
> clearer.
I don't really see that. No matter how this holding back thing were
implemented, it would need to have the behavior I have outlined, and it
would affect:
commit,
local-diff,
wc-to-* copy,
merge (print warning to add --do-not-hold to the next commit
OR set flag),
update/switch (print warning if prop gets removed,
iff there are local mods aka secrets).
These requirements do not change when you do it with changelists.
> Since TortoiseSVN has had this feature for a long time, it would
> be interesting to know what kind of edge cases people have raised with the
> feature. Has anyone asked that these files not be updated or merged?
I've asked, but only on this list... good point, I should ask tortoise devs
directly. (But their changelist is called "ignore-on-commit", so it's pretty
clear what it does, I guess.)
If we had a simple --exclude <glob> option to 'commit', maybe we wouldn't be
having this discussion today. There is to-date no easy way to tell svn to
skip single files (svn has no negatively acting options for this case).
So if svn:hold is defied, or maybe on top of it, too, I'd try to implement
such an option. But I still prefer svn:hold, because it adds the ability for
the senior developers to set default behavior in the WCs of junior
developers (yes, we are writing a centralized VCS, and many users want
centralizable config), and because you don't have to perpetually remember to
pass an --exclude option for the right WCs, at times where you're in the
middle of hacking on a patch.
Wow, I didn't think I'd have to argue this much :)
I still don't see how 'svn:hold' is problematic to include in 1.8.
More cons?
~Neels
Re: bring on your concerns about svn:hold, please
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Aug 22, 2011 at 10:32 AM, Neels J Hofmeyr <ne...@elego.de> wrote:
> Greg/anyone, do you have any more arguments against svn:hold except "people
> will trip over a prop they read the documentation of and set up themselves
> before it had any effect" -- because I don't think that's a real problem.
> They would have tripped over 'svn:ignore', 'svn:externals' and
> 'svn:keywords' long before tripping over 'svn:hold'. BTW, my intention is
> to
> clearly mark held-back local mods in 'svn status' (e.g. 'H'); particularly
> important for merge situations.
>
> In my vision, 'svn:hold' would be the exception, in the scale of one
> build.conf type of file per huge project tree. But that's up to the users.
> Which is exactly the point!
>
> (See notes/hold for more points.)
>
I really do not know where I stand on this. If you had asked me before you
started if it would be good to have a feature where certain local files
could be ignored by commit I would have said Yes. Now that you have started
working on it, and some more thought has gone into it I am less sure. I do
worry about the implications of a feature like this in terms of what the
behavior should be on other commands.
Maybe a different implementation could make a difference? Just thinking out
loud ....
What if SVN had a feature like TortoiseSVN where any file in a specifically
named changelist was automatically ignored on commit unless that specific
changelist is named ($ svn ci -cl ignored-files ) We could probably make
commands like status and diff automatically ignore this changelist too.
Perhaps we could then go a step farther with this feature by automatically
adding files with a special property like svn:hold to this changelist when
they are checked out?
Maybe if svn merge updates a file with this property it removes it from the
changelist so that it will be in the list of files to commit? svn commit
could add the file back to the changelist, just as a commit on a locked file
puts the read-only attribute back on the file?
An approach like this might be more complicated to implement but it avoids
adding new options, and I *think* it makes the behavior on other commands
clearer. Since TortoiseSVN has had this feature for a long time, it would
be interesting to know what kind of edge cases people have raised with the
feature. Has anyone asked that these files not be updated or merged?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
bring on your concerns about svn:hold, please
Posted by Neels J Hofmeyr <ne...@elego.de>.
On 08/22/2011 02:01 AM, Greg Stein wrote:
> I find the entire concept to be worrisome. All of a sudden, there are
> files that just don't act right. "Magic" occurs, and only on certain
> files. This just isn't very discoverable, and I think it will just
> trip people up. "Huh? Why didn't that commit? ... OH, SUCK."
>
> There is just too much mystery occurring with this proposed feature.
On 08/22/2011 08:48 AM, Johan Corveleyn wrote:
> To me the current proposal seems like a relatively clean and standard
> approach. It doesn't appear to be any more magical than other svn:
> props (ignore, keywords, eol-style, ...). Besides, I haven't seen
> other ideas yet on how to implement this useful feature.
>
> However: please keep it as simple and transparent as possible, at
> least initially. For instance, I'm not interested in holding 'update'
> (I currently see no firm use case for that). AFAICS, the main thing is
> holding 'commit'. Though I realize that other operations may need to
> be adapted as well (status, diff, info, ...), to keep it consistent
> and understandable for the user.
I do understand Greg's concerns, and I particularly find the aspect
worrisome where it adds *yet* another way to 'svn merge' to shoot oneself in
the foot.
OTOH:
- I strongly agree that we do *not* hold updates or anything else, except
commit. (With wc-copies, we should probably not copy local mods though, and
a diff of local mods should omit held-back stuff. But that's *all*.)
- forgetting to issue --do-not-hold when committing a merge can be countered
by appropriate warnings at the bottom of merge output, which appear only
when held-back files are touched by a merge. If this is a major concern, we
could set some flag on affected files which makes 'commit' bail if
--do-not-hold is missing after a merge involving held-back nodes.
- #svn, the issue tracker (and probably the users@ list too though I haven't
checked) perpetually bring up this "template" problem. Tortoise has a per-WC
solution; we just have dumb workarounds, really.
- the level of magic around proposed 'svn:hold' is consistent with other
props. Plus, any and all such magic is obliterated simply by absence of
'svn:hold' propsets, and/or by --do-not-hold. What more can you ask for.
- any performance concerns can be addressed by adding a boolean column to
the NODES table, kept up-to-date by any prop changing code. I actually doubt
that this is even necessary.
The feature is still on the branch 'hold'. I'd love to merge to trunk in the
near future, since my roadmap is pretty quick to implement apparently. *Or*
I'd toss the whole concept out the window.
I'd appreciate to read more concerns *against* svn:hold on this list,
because if I eventually toss the feature, I might as well do so now.
OR I'LL JUST FORK SVN!! nah just kidding :)
Greg/anyone, do you have any more arguments against svn:hold except "people
will trip over a prop they read the documentation of and set up themselves
before it had any effect" -- because I don't think that's a real problem.
They would have tripped over 'svn:ignore', 'svn:externals' and
'svn:keywords' long before tripping over 'svn:hold'. BTW, my intention is to
clearly mark held-back local mods in 'svn status' (e.g. 'H'); particularly
important for merge situations.
In my vision, 'svn:hold' would be the exception, in the scale of one
build.conf type of file per huge project tree. But that's up to the users.
Which is exactly the point!
(See notes/hold for more points.)
Vote: Merge branches/hold to trunk soon?
neels: +1
Thanks for opinions!
~Neels
Re: concerns about svn:hold -- was: svn commit: r1159240 - in
/subversion/branches/hold/subversion: include/private/svn_wc_private.h
include/svn_props.h libsvn_client/commit_util.c libsvn_wc/node.c
Posted by Johan Corveleyn <jc...@gmail.com>.
On Mon, Aug 22, 2011 at 2:01 AM, Greg Stein <gs...@gmail.com> wrote:
> On Sat, Aug 20, 2011 at 19:48, Neels J Hofmeyr <ne...@elego.de> wrote:
>>...
>> I have taken the occasion to write a comprehensive description of my current
>> vision for svn:hold.
>
> I find the entire concept to be worrisome. All of a sudden, there are
> files that just don't act right. "Magic" occurs, and only on certain
> files. This just isn't very discoverable, and I think it will just
> trip people up. "Huh? Why didn't that commit? ... OH, SUCK."
>
> There is just too much mystery occurring with this proposed feature.
FWIW, I do like this feature (as an svn user and overall CM person in
my company). I could certainly make good use of this in our
environment: for project and module files of the IDE, build scripts
("Makefile.in" and the like), ...
I do not want to bother every developer with that (putting them in a
changelist, ...), but just set it (and draft the template) centrally.
I only want them committed if someone explicitly decides to change the
template (--do-not-hold seems fine to me).
To me the current proposal seems like a relatively clean and standard
approach. It doesn't appear to be any more magical than other svn:
props (ignore, keywords, eol-style, ...). Besides, I haven't seen
other ideas yet on how to implement this useful feature.
However: please keep it as simple and transparent as possible, at
least initially. For instance, I'm not interested in holding 'update'
(I currently see no firm use case for that). AFAICS, the main thing is
holding 'commit'. Though I realize that other operations may need to
be adapted as well (status, diff, info, ...), to keep it consistent
and understandable for the user.
--
Johan
Re: concerns about svn:hold -- was: svn commit: r1159240 - in
/subversion/branches/hold/subversion: include/private/svn_wc_private.h
include/svn_props.h libsvn_client/commit_util.c libsvn_wc/node.c
Posted by Greg Stein <gs...@gmail.com>.
On Sat, Aug 20, 2011 at 19:48, Neels J Hofmeyr <ne...@elego.de> wrote:
>...
> I have taken the occasion to write a comprehensive description of my current
> vision for svn:hold.
I find the entire concept to be worrisome. All of a sudden, there are
files that just don't act right. "Magic" occurs, and only on certain
files. This just isn't very discoverable, and I think it will just
trip people up. "Huh? Why didn't that commit? ... OH, SUCK."
There is just too much mystery occurring with this proposed feature.
Cheers,
-g