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

Re: [BUG] Conflict with use-commit-times = yes + svn:keywords set

From: Brian W. Fitzpatrick <fitz_at_collab.net>
Date: 2004-11-02 19:26:18 CET

On Nov 2, 2004, at 12:07 PM, C. Michael Pilato wrote:

> "Brian W. Fitzpatrick" <fitz@collab.net> writes:
>> However, perhaps we could add a feature to cvs2svn that does one final
>> commit to keyword-enabled files to unexpand the keywords. Dunno if
>> it's worth it tho.
> I started composing an email to suggest just this, but then realized
> that doing this would be pointless, because all old revisions would
> still have this problem, and because you'd have to do the commits
> across all the files in all the tags and branches. Untenable.

*sigh* You're right.

>>> 2) Subversion is patched to unexpand keywords when checking out a
>>> file (since it already handles diff against an unexpanded text-base).
>>> I'm inclined to think that #1 is the most appropriate solution (on
>>> the GIGO principle), but #2 is probably not /that/ hard to do
>>> (having spent some time in that section of the code).
>> Hmm. I don't know if it's worth it though.
> We already do something of the sort in the export case (though in
> reverse -- we expand the keywords). It would possible cause yet
> another performance hit in the checkout case, but at least would only
> be triggered for files that have the keywords property set.

Sure, but then what's the point of having the silly things in the
repository at all if you're going to do that?

> And we could always add an option for "not doing that."

True enough, but another switch for this weird edge case? Ew.

On further thought, I think I'd just prefer a cvs2svn switch to disable
keyword expansion while still setting the keyword property on the
appropriate files.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 2 19:26:56 2004

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.