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

Re: automatic keyword un-expansion on 'svn {ps,pd,pe} svn:keywords'?

From: <kfogel_at_collab.net>
Date: 2006-03-15 20:05:27 CET

Julian Foad <julianfoad@btopenworld.com> writes:
> I'll just mention a few points.
>
> When a user asks Subversion to stop handling a keyword,
>
> * some will want to remove the entire keyword from the text;
>
> * some will want to keep the last expanded value as ordinary versioned text;
>
> * some will want to keep an empty, contracted keyword placeholder in the text.
>
> The first requires manual editing, and that's fine. Of the second and
> third, do we have a hope of guessing which is more common?
>
> Is it "svn diff" that we should be fixing, rather than "propdel"?
>
> Consider the dangers of modifying a file while it might be open in a
> user's editor. The same dangers apply to "update", "merge", etc., so
> it's "just" a matter of user education, but text changes caused by a
> property command is a new phenomenon.
>
> If we are going to contract the keyword, consider doing it at commit
> time rather than at prop-change time, as that would avoid the
> text-change problem. (Do what, exactly? Contract the set of keywords
> that is the union of base and working prop values?)
>
> More thought required.

Hmmm. What you say makes me think that showing a "local mod" (the
still-expanded keyword) after the propdel might be at least as useful
as automatically contracting the keyword. And showing the local mod
alerts the user that there's a conscious decision to be made here.

My (mild) inclination is to stay with status quo now. The diff may be
annoying, but at least it's not a silent change.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 15 21:55:34 2006

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

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