(snip)
> > > Anyone who can respond to the real issue? Will timestamp metadata
> > > preservation make to the 1.3 release?
> >
> > I don't think anyone's working on it.
> >
> > The reason the feature doesn't exist is because a formal design has
> > never been proposed or discussed. Ph. Marek was kind
> enough to code
> > up something "which works", but that branch has never been
> merged to
> > trunk. It won't be merged until someone picks up the lead on this
> > feature and leads the design discussion.
> >
>
> But issue # 1256
> (http://subversion.tigris.org/issues/show_bug.cgi?id=1256) is
> marked as 1.3-consider and status 'started', assigned to kfogel.
>
> Doesn't this mean that someone is working on it? Or has it
> been marked as started since 2003? ;(
(snip)
I saw that, I hope it means kfogel is indeed working on it...
As for the design discussion - what is required? It seems fairly
straightforward, especially as there is a working sample of code.
I'll be willing to lead that discussion, but out of necessity it'll have to
be fairly high level to start with, not having studied the code or design of
SVN at all.
Perhaps I'm naive, but something like this might serve as the start of this
design discussion:
- Design goal: Import followed by export/checkout from the same client
system should be a no-operation affecting nothing of file contents
bit-for-bit or the meta data "file name" and "file timestamps".
- When checking out on a different file system than imported from, the best
possible approximation should be done. Filenames are treated as today.
Timestamps are rounded to the nearest value in the target file system
resolution. If exactly half, always round up to a more recent time (err on
the side of a non-existing update rather than the other way).
- Add two more meta-data (properities I suppose) to the repository:
time-last-modified and time-created.
- Default behavior at import is use what is available on the local file
system for time-last-modified and time-created. If only one timestamp is
available use it only for time-last-modified , and leave time-created
undefined.
- Default behavior at export is use available properties. If time-created is
available use it for that. If time-last-modified is availabled use it for
that. If the local file system only supports one time stamp, use
time-last-modified and ignore time-created even if available. If neither
time-last-modified or time-created is available, use current behavior.
- Default behavior at checkout is current behavior (for compatibility). Add
a client-side switch analogous to the use-commit-times, use-file-times
perhaps. When set, both export and checkout use the defined behavior.
- Store times with resolution and time zone information (UTC I presume) as
is now done for commit times.
- If time-last-modified or time-created is in the future from the view of
the server at import/export/checkout do nothing, just accept it (possibly
inform). (If the user for whatever reason wants this - that's her choice.
The repository should not police such a situation).
I'm sure there are file system quirks, and possible SVN design issues, that
makes some things need to be handled differently than above, please comment
on this.
Svante
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 19 11:53:21 2005