[cvsnt] Re: Catch-all solution for changing -k modes?

[Oliver Giesen]

Tony Hoyle wrote:

> Actually the -f requirement is for compatibility.... it's not
> uncommon to do an update -k to export a sandbox without keywords for
> example... if that sandbox is then committed it'd reset all the
> expansions - the -f requirement means you can't do that accidentally

OK, I didn't think of that admittedly. In that case I suggest
differentiating between merely making a k-option sticky temporarily for
a local working copy and actually changing the k-option as part of a
versioned operation. IMO the latter should use a different option, e.g.
-K . This then could have the effects I described before (i.e. modified
timestamp token in Entries and consequently no more need to specify -f
on commit(?)).

I really find the current behaviour a bit confusing as it mixes
semantics. Then again, if it was done the way I just suggested I would
no longer be able to use my catch-all command sequence... :/


> Remember that on older CVS the admin -k option is destructive - any
> revisions stored using the older expansion will now have the new one
> (and may therefore be incorrect).  CVSNT pre-2.0.58 has a slightly
> less severe version of this problem in that you can only have a
> single default -k option for every branch of the file.  It's worth
> mentioning this probably in the help for any option that wraps
> expansion changes.

Understood.

 
> It's probably never made much sense - it could do now

You mean your current development build? I tested it with 2.0.62.1810
and it definitely doesn't there (talking about up -A resetting
k-options).


> (IMO up -A should reset to the original expansion for that option)

Yes, that's what I'd expect it to as well. At least if by "original"
you mean the k-option of the base revision.


> - it needs sorting out one way or the other.

Agreed.

Cheers,

-- 
Oliver
----  ------------------
JID:  ogiesen at jabber.org
ICQ:  18777742     (http://wwp.icq.com/18777742)