"P.Marek" <pmarek@users.sourceforge.net> writes:
> it's me again. Now I've got a patch against 0.23.0 which saves the
> timestamps on add, import and commit, and restores these on export
> (but not update).
Hi Philipp,
Sorry that nobody's been giving you feedback here... we've all been
pretty busy! I'm glad you're working on this issue.
Timestamp-preservation is a complex feature, just like eol-translation
and keywords (which tooks us *weeks* to write and debug). I think it
needs a lot of design discussion. Previous list threads on this topic
haven't gone very far and gotten a bit muddled... and so now I'm
worried that you're off in the corner, writing huge patches, but
getting no developer feedback as to whether you're moving in the
"correct" direction or not.
So I'd like to talk about this feature some more, if you don't mind.
Here I am. :-)
> As of now I believe there should be a sub-class of
> "svn:"-properties, which are called "volatile" in the code, and
> which hold the os-specific properties - that would be
> svn:executable, svn:text-time, svn:acl (when we've got these), and
> so on. But I'd like to get some feedback first.
Yeah, I don't think the idea of "volatile" properties is gonna fly.
Properties that users can manipulate (via 'svn propset') are normal,
versioned things. It sounds like you want *unversioned* metadata
attached to each file... and we already have a mechanism for that. We
call them "entry" props, and they live in the .svn/entries file.
They're marshalled over the network (from server to client only) with
the svn:entry: prefix, then stashed in .svn/entries. The user never
sees them, unless they run 'svn info' on a file. For example, many of
the values that get expanded into keywords (changed rev, changed date,
author) are "entry" props.
> Any help appreciated :-)
A random tip: this project has a lot of coding practices and
policies, all documented in our HACKING file. It's pretty hard to get
people to review large patches if you don't supply a detailed log
message that orients the reviewer to the "big picture." Your latest
patch has no log message at all. Your earlier patch is just a list of
files, followed by 2 sentences of feature description. Try running
'svn log' on svn's own tree, to see the level of detail HACKING
requires. :-)
That said... I'm going to start a new mail thread in just a second, so
we can work out a nitty-gritty detailed design.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 19 16:13:36 2003