On Tuesday 22 November 2005 20:37, Mark Phippard wrote:
> As I have understood this issue from past messages, the problem is that
> the Devs have been looking for a design proposal. Right now there is a
> patch and there are some emails that explain what it does etc.. But what
> they would really like to see is a design proposal for the feature that
> can be discussed and agreed upon. Once that is done, then the patch can
> begin to be reviewed and modified such that it corresponds to the design
> document.
>
> If you want to do something, forget that this patch exists and try to
> instead begin the process of designing the feature. If the feature is
> agreed upon and well-designed then there might be more developer interest
> in tackling it.
So, to get at least the brainstorming startet, I'll try to recreate my
thoughts from 2003.
What is wanted?
- To save the (modification-) timestamp for each committed file, and
to restore them.
- Must be specifiable per-file, so that single documents within a source
tree can use that feature, but all others not.
- Must not be manually specified for each added/imported file.
For added it's too much work (or a separate script would be needed), and
on import it's already to late (imported version has no saved timestamps).
So, pondering on these points, I got to thoughts about a solution.
- A distinct script (like asvn at that time) would have to travel through
the source tree to record the mtime, then svn would crawl again for commit.
This leads to race conditions and was unacceptable for me at that time (too
big a wc).
If svn does that itself there would be mere milliseconds between stat()ing
the file
- The mtime could either be stored as a property for the respective file, in
another repository which mirrors the tree structure of the "data"-
repository, in a mirror tree in the same repository or somewhere else
(textfiles, SQL database, etc.).
The only "Right" solution for me was to store beneath the file, ie. as a
property (which is what properties are for, after all).
Next conclusion was to modify svn - as that already travels the wc, knows
which files are modified and about to be committed, handles properties and
knows how to store them.
- svn could have a new command "set the mtime properties of file X, Y, and Z".
- Could be forgotten.
- svn could update a property automatically, if this property already exists.
So all tiles fall into place, and we arrive at my patch.
Tell me where I went wrong, and we'll discuss.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 23 07:15:56 2005