Ph. Marek wrote:
> On Tuesday 22 November 2005 20:37, Mark Phippard wrote:
>
>>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?
OK, this "What is wanted?" section is important. It's the basic Requirements.
> - To save the (modification-) timestamp for each committed file, and
> to restore them.
Good: that's the basic statement of what the whole thing is about.
> - 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).
These two points are the beginning of the details of the requirements.
[...]
> The only "Right" solution for me was to store beneath the file, ie. as a
> property (which is what properties are for, after all).
Yes, absolutely.
[...]
> - svn could update a property automatically, if this property already exists.
Yes, that's logical.
> So all tiles fall into place, and we arrive at my patch.
>
> Tell me where I went wrong, and we'll discuss.
So far, so good.
Next, develop the requirements section into a more detailed design
specification that will satisfy those requirements (and all the unstated
requirements). Write this by saying exactly what the software will do,
functionally, from a user's point of view, with enough precision that the
reader can work out what would happen in a complicated scenario. For example,
the reader should be able to determine what mtime would be used on FILE after a
sequence like:
svn revert FILE
svn cat -rHEAD FILE > FILE
touch --date=yesterday FILE
svn update FILE"
and other sequences of Subversion and non-Subversion commands.
The requirements spec should read a bit like a "man page" for the feature:
saying exactly what it will do in every possible circumstance, how it interacts
with other features, how it's controlled, etc. One significant difference is
that the design spec does not need to state the exact syntax used (property
names and values, configuration options, command-line options, etc.). Those
details need not be fixed until later, but you can mention them if you've
already chosen them.
To get started, here are some prompts:
- Start with a little introduction that says what the basic requirement is,
that the timestamp to be saved is the mtime, that it is saved in a property, etc.
- How is the mtime saved?
- For what items (files? dirs? symlinks?)
- What conditions are required (property existing, configuration, etc.)
- At what times: in "commit", in "import", in "copy WC URL", etc.
- Can an mtime be saved for an item that didn't exist in WC (e.g. "mkdir URL")?
- What happens to the mtime of an item that is copied/moved/deleted in the
repository (if it's not obvious from what was said in the introduction)?
- Can the saving of mtimes be controlled independently from the restoring of
mtimes?
- How is the mtime restored?
- What factors can affect whether the mtime is restored - at the time when
it was saved? at the time when it is to be restored?
- How does this mtime restoration interact with the "use commit times"
feature that already exists?
- ...
- What are the issues with regard to precision? (Different file systems store
mtime with differing precisions.)
The design spec shouldn't necessarily answer these questions directly, it
should just contain enough facts to enable questions like these to be answered.
I hope that's a help. Don't hesitate to make a start on it and then post a
partial spec for further advice.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Nov 27 21:55:53 2005