kfogel@collab.net wrote:
> I understand that the problem is thorny, and that changing cvs2svn's
> behavior is not an easy answer here either. But one of the inviolable
> rules of the working copy has always been that a file's text-base is
> byte-for-byte the same as that file in the repository.
Except that the data in the repository is, arguably, malformed due to
the presence of expanded keywords. The current codebase makes the
assumption that /if/ keywords are used on a file, /then/ they are stored
unexpanded in the repository. Unfortunately, it's very easy to mess
this up, since the only time a file is checked for expanded keywords is
when the file, not the svn:keywords prop, is committed.
> It sounds like this solution breaks that that rule -- that now, the
> text-base would be different from the data in the repository, because
> the text-base would store an unexpanded keyword value, when that value
> is stored expanded in the repository. That's... bad.
>
> Am I maybe misunderstanding the proposal being made here?
No, I don't think you are. However, I see a couple of ways to handle
this disjoint between the repository and the WC text-base:
1) silently unexpand existing keywords when writing out the text-base (I
tend to think this is wrong too, BTW, now that you point it out);
2) make the wc code unexpand the text-base before comparing (I don't
know how hard this is, since I haven't followed that side of the process
in the codebase); at the very least, this is a performance penalty for
every file with keywords (more than usual);
3) make the client code check the text-base when the svn:keywords
property is set, and either
a) silently unexpand keywords and commit the file _and_ the revprop, or
b) refuse to set the property until the file is fixed (or --force used,
in which case follow 3a).
I think that from the standpoint of not losing any data, I am leaning
towards 3b as the most conservative method. This would maintain a trail
of what the file contained before the revprop was set. This would "fix"
the bad data in the repository so that the rest of the code base could
remain unchanged. And finally, this would also correctly handle the
situation where the local WC has changes and the user can decide whether
to commit both the changed file and the revprop, or neither.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 3 19:06:47 2004