On Mon, 7 Nov 2005, Julian Foad wrote:
> Peter N. Lundblad wrote:
> >
> > But, maybe I'm wrong and we must keep this prop-time just because svn info
> > outputs it? BTW, it is not always available (sachedule ad comes to mind),
> > so people can't just blindly rely on its existence.
>
> I suspect "svn info" arose as a debugging aid, and not all of what it prints
> would have been designed into such a feature intended for end-users.
Yeah, to me it looks more or less like a user-friendly dump of the entry
(except for the URL variant, of course.)
> Personally I'd be happy to not have the "Props Last Updated" field.
> However, I think it would be a pretty bad compatibility decision to
> remove it before version 2. Therefore I think it needs to stay. (If
> you don't combine the various props files into fewer, you could perhaps
> use their on-disk last-modified time stamps instead.)
>
The problem is that it becomes meaningless when there only is a props file
when properties are changed. BTW, what guarantee do we *really* have about
this? When you update, property timestamp is only updated if there were no
local mods *before* the new props were installed. The same applies for
text-base. What use could a user have for this info?
> > I think it would be good to get rid of it both for code cleanliness and
> > because it saves some space in the entries file.
>
> Maybe simplify the code by not using it, but keep it just for "svn
> info".
>
It will have to stay for that for compatibility with format 5 and earlier.
We upgrade the format on the first open-for-writing.
If we say that the guarantee is that prop-time is output by info if
available in the WC entry, then we don't break the guarantee by removing
it from the entry:-)
> The space it takes in the entries file is something around 10%, a noticeable
> proportion but not important, and certainly not a significant proportion of
> Subversion's overall space overhead.
>
I'm mostly concerned about the time it takes to read and parse the XML.
We're adding some new fields to the entry. It could be good to remove one
field that is not needed in practice.
Anyone else has an opinion on this one?
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 7 21:44:42 2005