You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Ph. Marek" <ph...@bmlv.gv.at> on 2005/11/23 06:11:45 UTC
[DESIGN] mtime versioning - was: Getting Bug 1256 fixed
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
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Monday 28 November 2005 13:58, Giovanni Bajo wrote:
> > That's why my patch only stores for files _with svn:text-time set_. All
> > others are treated as before.
>
> Thus, are you proposing this property not to be added by default (unless
> one modifies its own Subversion configuration file)? What if I want mtime
> stored only for imported trees? Will the flag work also for directories?
You can use auto-props to set the property depending on filename, eg. *.doc.
You can give svn a parameter to use an alternate configuration file, eg. to
have mtime stored with every file on import.
In the owner-group-mode branch this is also done for directories.
> I know there is a long-time bug with CVS and DST, but I don't remember the
> details. Google brought up this link:
> http://www.devguy.com/fp/cfgmgmt/cvs/#DST. I suggest the problem to be
> investigated in detail so to find out if it can be avoided in SVN.
I don't think that would confuse svn.
> There
> are also other issues with the rouding of mtime on different filesystems
> (e.g. when you store a file into a FAT-16 disk and you read the mtime back,
> it can be modified by rounding). This can cause trouble too; eg. SVN might
> think that the user modified the mtime of the file while it was just
> rounded by the filesystem.
Yes, but that's inevitable. Therefore svn does a file data comparision before
saying that a file is modified.
> Anyway the issue is moot if this feature is opt-in rather than opt-out by
> default. Personally, I would turn it manually on only on import.
My patch only provides mechanism, not policy :-)
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by Giovanni Bajo <ra...@develer.com>.
Ph. Marek <ph...@bmlv.gv.at> wrote:
>> It's not clear to me whether "svn up -rN" should restore the modification
>> time of the files at that revision. If so, that would break a common
usage
>> pattern such as:
> ...
>> I took some time to search the archive for previous discussions about
mtime
>> versioning. After some reading, the only argument that convinced me is
that
>> of importing external trees.
> And every other usage which does not involve make, eg. documents.
Ah right. I never used Subversion for other kind of data, so this is why I'm
biased towards source code repositories.
>> In my mind, it would be "svn import" *only* to
>> remeber the mtime of the files being imported (at least by default), so
>> that it can be restored later. I still fail to see what's good in having
>> "svn commit" records and stores the mtime of each and every file.
> That's why my patch only stores for files _with svn:text-time set_. All
> others are treated as before.
Thus, are you proposing this property not to be added by default (unless one
modifies its own Subversion configuration file)? What if I want mtime stored
only for imported trees? Will the flag work also for directories?
>> Off the
>> top of my head, you will also have to fight endless trouble with
timezones,
>> DST, different time encoding in Windows and UNIX, and whatnot.
> If you take a look into the stored timestamps you'll see that they look
like
> this:
> 2005-11-21T06:51:45.000000Z
> i.e. are stored in a text-format, UTC. Resolution up to microseconds, all
> conversions are done by svn. Which trouble could there be?
I know there is a long-time bug with CVS and DST, but I don't remember the
details. Google brought up this link:
http://www.devguy.com/fp/cfgmgmt/cvs/#DST. I suggest the problem to be
investigated in detail so to find out if it can be avoided in SVN. There are
also other issues with the rouding of mtime on different filesystems (e.g.
when you store a file into a FAT-16 disk and you read the mtime back, it can
be modified by rounding). This can cause trouble too; eg. SVN might think
that the user modified the mtime of the file while it was just rounded by
the filesystem.
Anyway the issue is moot if this feature is opt-in rather than opt-out by
default. Personally, I would turn it manually on only on import.
--
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Monday 28 November 2005 13:11, Giovanni Bajo wrote:
> It's not clear to me whether "svn up -rN" should restore the modification
> time of the files at that revision. If so, that would break a common usage
> pattern such as:
...
> I took some time to search the archive for previous discussions about mtime
> versioning. After some reading, the only argument that convinced me is that
> of importing external trees.
And every other usage which does not involve make, eg. documents.
> In my mind, it would be "svn import" *only* to
> remeber the mtime of the files being imported (at least by default), so
> that it can be restored later. I still fail to see what's good in having
> "svn commit" records and stores the mtime of each and every file.
That's why my patch only stores for files _with svn:text-time set_. All others
are treated as before.
> Off the
> top of my head, you will also have to fight endless trouble with timezones,
> DST, different time encoding in Windows and UNIX, and whatnot.
If you take a look into the stored timestamps you'll see that they look like
this:
2005-11-21T06:51:45.000000Z
i.e. are stored in a text-format, UTC. Resolution up to microseconds, all
conversions are done by svn. Which trouble could there be?
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by Giovanni Bajo <ra...@develer.com>.
Ph. Marek <ph...@bmlv.gv.at> wrote:
> - To save the (modification-) timestamp for each committed file, and
> to restore them.
It's not clear to me whether "svn up -rN" should restore the modification
time of the files at that revision. If so, that would break a common usage
pattern such as:
svn up -r1234 foo.h
make # rebuild only files affected by the foo.h change
which would be IMHO a regression (at least if done by default). Another
broken one would be:
touch foo.h # local modifies
make
svn revert foo.h
make # should always rebuild!
I took some time to search the archive for previous discussions about mtime
versioning. After some reading, the only argument that convinced me is that
of importing external trees. In my mind, it would be "svn import" *only* to
remeber the mtime of the files being imported (at least by default), so that
it can be restored later. I still fail to see what's good in having "svn
commit" records and stores the mtime of each and every file. Off the top of
my head, you will also have to fight endless trouble with timezones, DST,
different time encoding in Windows and UNIX, and whatnot.
If you are going to post an updated design as suggested by Julian, make sure
to have a section with use cases (aka motivating reasons) for this feature.
--
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by Peter McNab <mc...@melbpc.org.au>.
Malcolm Rowe wrote:
>On Mon, Nov 28, 2005 at 06:59:18AM -0500, John Szakmeister wrote:
>
>
>>Properties change a lot less than the underlying file, so I believe the
>>number of deltas involved would be considerably smaller than what you would
>>expect for a file.
>>
>>
>
>If we're storing the mtime of the file in a revision, we'd expect the
>property to change on every commit.
>
>Regards,
>Malcolm
>
>
I'm not and never will be an svn developer so please go easy.
Because svn stores folder information could the file time be stored more
efficiently in the svn folder structure information?
I would expect file times at import and at "add" to be preserved on the
subsequent Checkout / Update but on those files only.
Same, if the "TakeOver" feature eventuates.
Whilst it might seem consistent to also preserve the last modified time
for commits there is a strong case to always stamp files existing in the
WC with the update time. (Time at which the local copy is updated from
the repo)
Consider the situation where two clients are simultaneously working on a
project, compiling only if the source file date is newer than an
intermediate file e.g. .obj or .dcu etc.
Client A modifies file x and commits the change.
Client B updates file x and it's date is stamped with Client A's last
modified date/time.
But Client B's intermediate file is newer than Client A's modified file,
so the compiler skips the new source and re-uses the now out of date
existing intermediate file again. That looks difficult to detect.
Same situation can also occur even if the file is stamped with the time
of commit into the repository by Client A.
my 2c worth
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by Erik Huelsmann <eh...@gmail.com>.
On 11/28/05, Malcolm Rowe <ma...@farside.org.uk> wrote:
> On Mon, Nov 28, 2005 at 06:59:18AM -0500, John Szakmeister wrote:
> > Properties change a lot less than the underlying file, so I believe the
> > number of deltas involved would be considerably smaller than what you would
> > expect for a file.
>
> If we're storing the mtime of the file in a revision, we'd expect the
> property to change on every commit.
Do we? Or only when the text files' contents has also changed?
bye,
Erik.
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by John Szakmeister <jo...@szakmeister.net>.
Malcolm Rowe wrote:
> On Mon, Nov 28, 2005 at 06:59:18AM -0500, John Szakmeister wrote:
>> Properties change a lot less than the underlying file, so I believe the
>> number of deltas involved would be considerably smaller than what you would
>> expect for a file.
>
> If we're storing the mtime of the file in a revision, we'd expect the
> property to change on every commit.
Good point!
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by John Szakmeister <jo...@szakmeister.net>.
Malcolm Rowe wrote:
> On Mon, Nov 28, 2005 at 06:59:18AM -0500, John Szakmeister wrote:
>> Properties change a lot less than the underlying file, so I believe the
>> number of deltas involved would be considerably smaller than what you would
>> expect for a file.
>
> If we're storing the mtime of the file in a revision, we'd expect the
> property to change on every commit.
Good point!
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by Erik Huelsmann <eh...@gmail.com>.
On 11/28/05, Malcolm Rowe <ma...@farside.org.uk> wrote:
> On Mon, Nov 28, 2005 at 06:59:18AM -0500, John Szakmeister wrote:
> > Properties change a lot less than the underlying file, so I believe the
> > number of deltas involved would be considerably smaller than what you would
> > expect for a file.
>
> If we're storing the mtime of the file in a revision, we'd expect the
> property to change on every commit.
Do we? Or only when the text files' contents has also changed?
bye,
Erik.
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Mon, Nov 28, 2005 at 06:59:18AM -0500, John Szakmeister wrote:
> Properties change a lot less than the underlying file, so I believe the
> number of deltas involved would be considerably smaller than what you would
> expect for a file.
If we're storing the mtime of the file in a revision, we'd expect the
property to change on every commit.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Mon, Nov 28, 2005 at 06:59:18AM -0500, John Szakmeister wrote:
> Properties change a lot less than the underlying file, so I believe the
> number of deltas involved would be considerably smaller than what you would
> expect for a file.
If we're storing the mtime of the file in a revision, we'd expect the
property to change on every commit.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by John Szakmeister <jo...@szakmeister.net>.
On Monday 28 November 2005 06:25, Julian Foad wrote:
> Malcolm Rowe wrote:
> > On Mon, Nov 28, 2005 at 09:59:06AM +0100, Ph. Marek wrote:
> >>- space on harddisk - this is *currently* important! A wc with 1000 files
> >> with no properties other than svn:text-time on a 4kB filesystem needs
> >> 1000 * 2 * 4k ~ about 8MByte *only for this properties*!
> >> Now go to a wc with 100000 files ... and 800M are gone.
>
> You say "800M are gone" as if it's a bad thing, but if the whole WC
> occupies 10 GB or so then it's trivial.
True, for a large working copy in terms of raw size. However, if you have
100,000 files that are all pretty small (source files, for example). Then
it's possible that the props are occupying a significant amount of space in
relation to the overall size of the WC.
> >> Although matters are progressing on this front.
> >
> > That's quite significant. Also, files do not typically have properties
> > (with the possible exception of svn:eol-style), and there's a fair amount
> > of optimisation that's been done lately to improve matters in that case.
> > Adding svn:text-time to all files unconditionally would probably be a
> > bad idea.
>
> You're both doing "premature optimisation". Concentrate on what would be
> functionally desirable, and THEN determine if we need to make any
> improvementes in efficiency, and we'll make them. Mention the inefficiency
> as a caveat, don't treat it as a show-stopper.
/me agrees.
> > [Note that the FSFS format has the capability to store properties as
> > deltas against earlier versions, but the implementation doesn't currently
> > do that, presumably at least partly because properties are considered to
> > be things that change infrequently - and so doing so probably wouldn't
> > be worth the effort in terms of space saved, and would also mean it
>
> Looks like you got your argument back to front there :-)
>
> > would take longer to reconstruct the properties during a read.]
>
> Premature optimisation again - unless you have measured that speed loss and
> found it to be unacceptably large, which I seriously doubt.
FWIW, I don't think the time difference would be all that significant.
Properties change a lot less than the underlying file, so I believe the
number of deltas involved would be considerably smaller than what you would
expect for a file. BTW, there are some people out there putting quite a bit
of information into their properties (>1MB), so perhaps we should really take
a look at how properties are stored at some point... but not in this
thread. :-)
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by John Szakmeister <jo...@szakmeister.net>.
On Monday 28 November 2005 06:25, Julian Foad wrote:
> Malcolm Rowe wrote:
> > On Mon, Nov 28, 2005 at 09:59:06AM +0100, Ph. Marek wrote:
> >>- space on harddisk - this is *currently* important! A wc with 1000 files
> >> with no properties other than svn:text-time on a 4kB filesystem needs
> >> 1000 * 2 * 4k ~ about 8MByte *only for this properties*!
> >> Now go to a wc with 100000 files ... and 800M are gone.
>
> You say "800M are gone" as if it's a bad thing, but if the whole WC
> occupies 10 GB or so then it's trivial.
True, for a large working copy in terms of raw size. However, if you have
100,000 files that are all pretty small (source files, for example). Then
it's possible that the props are occupying a significant amount of space in
relation to the overall size of the WC.
> >> Although matters are progressing on this front.
> >
> > That's quite significant. Also, files do not typically have properties
> > (with the possible exception of svn:eol-style), and there's a fair amount
> > of optimisation that's been done lately to improve matters in that case.
> > Adding svn:text-time to all files unconditionally would probably be a
> > bad idea.
>
> You're both doing "premature optimisation". Concentrate on what would be
> functionally desirable, and THEN determine if we need to make any
> improvementes in efficiency, and we'll make them. Mention the inefficiency
> as a caveat, don't treat it as a show-stopper.
/me agrees.
> > [Note that the FSFS format has the capability to store properties as
> > deltas against earlier versions, but the implementation doesn't currently
> > do that, presumably at least partly because properties are considered to
> > be things that change infrequently - and so doing so probably wouldn't
> > be worth the effort in terms of space saved, and would also mean it
>
> Looks like you got your argument back to front there :-)
>
> > would take longer to reconstruct the properties during a read.]
>
> Premature optimisation again - unless you have measured that speed loss and
> found it to be unacceptably large, which I seriously doubt.
FWIW, I don't think the time difference would be all that significant.
Properties change a lot less than the underlying file, so I believe the
number of deltas involved would be considerably smaller than what you would
expect for a file. BTW, there are some people out there putting quite a bit
of information into their properties (>1MB), so perhaps we should really take
a look at how properties are stored at some point... but not in this
thread. :-)
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Mon, Nov 28, 2005 at 11:25:23AM +0000, Julian Foad wrote:
> Malcolm Rowe wrote:
> >On Mon, Nov 28, 2005 at 09:59:06AM +0100, Ph. Marek wrote:
> >
> >>- space on harddisk - this is *currently* important! A wc with 1000 files
> >> with no properties other than svn:text-time on a 4kB filesystem needs
> >> 1000 * 2 * 4k ~ about 8MByte *only for this properties*!
> >> Now go to a wc with 100000 files ... and 800M are gone.
>
> You say "800M are gone" as if it's a bad thing, but if the whole WC
> occupies 10 GB or so then it's trivial.
>
Sure. The Subversion trunk is 2000 files in 50~60M, so an extra 16M
(~25%) would be a pain, though not particularly significant. Users of
the gcc repository might disagree, but I suspect they're not planning
to use this feature anyway.
Note that I originally misread Philipp's note as 'a wc with 1000 files
... and 800M are gone', which _would_ have been quite a big deal,
premature optimisation or no. Now that I re-read it, I see he was
talking about a significantly smaller overhead than I first realised.
> You're both doing "premature optimisation". Concentrate on what would be
> functionally desirable, and THEN determine if we need to make any
> improvementes in efficiency, and we'll make them. Mention the inefficiency
> as a caveat, don't treat it as a show-stopper.
>
Yes, absolutely - and that was what I intended. We should consider the
impact, and make sure we don't do anything truly stupid, but that's all.
>
> >[Note that the FSFS format has the capability to store properties as
> >deltas against earlier versions, but the implementation doesn't currently
> >do that, presumably at least partly because properties are considered to
> >be things that change infrequently - and so doing so probably wouldn't
> >be worth the effort in terms of space saved, and would also mean it
>
> Looks like you got your argument back to front there :-)
ITYM 'guess' rather than argument. I've no real knowledge as to why
the FSFS implementation doesn't produce deltas for properties.
> >would take longer to reconstruct the properties during a read.]
>
> Premature optimisation again - unless you have measured that speed loss and
> found it to be unacceptably large, which I seriously doubt.
>
No, not premature optimisation this time: it _would_ take longer to
reconstruct the properties if they were stored as deltas.
Whether it would take significantly longer is something we'd have to
measure later, though only if we first decided that the overhead from
rewriting the properties each revision meant that we should deltify the
properties too ... and we'd have to measure that too :-)
(I think we're in agreement, though perhaps I need to work on my
communication skills)
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Mon, Nov 28, 2005 at 11:25:23AM +0000, Julian Foad wrote:
> Malcolm Rowe wrote:
> >On Mon, Nov 28, 2005 at 09:59:06AM +0100, Ph. Marek wrote:
> >
> >>- space on harddisk - this is *currently* important! A wc with 1000 files
> >> with no properties other than svn:text-time on a 4kB filesystem needs
> >> 1000 * 2 * 4k ~ about 8MByte *only for this properties*!
> >> Now go to a wc with 100000 files ... and 800M are gone.
>
> You say "800M are gone" as if it's a bad thing, but if the whole WC
> occupies 10 GB or so then it's trivial.
>
Sure. The Subversion trunk is 2000 files in 50~60M, so an extra 16M
(~25%) would be a pain, though not particularly significant. Users of
the gcc repository might disagree, but I suspect they're not planning
to use this feature anyway.
Note that I originally misread Philipp's note as 'a wc with 1000 files
... and 800M are gone', which _would_ have been quite a big deal,
premature optimisation or no. Now that I re-read it, I see he was
talking about a significantly smaller overhead than I first realised.
> You're both doing "premature optimisation". Concentrate on what would be
> functionally desirable, and THEN determine if we need to make any
> improvementes in efficiency, and we'll make them. Mention the inefficiency
> as a caveat, don't treat it as a show-stopper.
>
Yes, absolutely - and that was what I intended. We should consider the
impact, and make sure we don't do anything truly stupid, but that's all.
>
> >[Note that the FSFS format has the capability to store properties as
> >deltas against earlier versions, but the implementation doesn't currently
> >do that, presumably at least partly because properties are considered to
> >be things that change infrequently - and so doing so probably wouldn't
> >be worth the effort in terms of space saved, and would also mean it
>
> Looks like you got your argument back to front there :-)
ITYM 'guess' rather than argument. I've no real knowledge as to why
the FSFS implementation doesn't produce deltas for properties.
> >would take longer to reconstruct the properties during a read.]
>
> Premature optimisation again - unless you have measured that speed loss and
> found it to be unacceptably large, which I seriously doubt.
>
No, not premature optimisation this time: it _would_ take longer to
reconstruct the properties if they were stored as deltas.
Whether it would take significantly longer is something we'd have to
measure later, though only if we first decided that the overhead from
rewriting the properties each revision meant that we should deltify the
properties too ... and we'd have to measure that too :-)
(I think we're in agreement, though perhaps I need to work on my
communication skills)
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by Julian Foad <ju...@btopenworld.com>.
Malcolm Rowe wrote:
> On Mon, Nov 28, 2005 at 09:59:06AM +0100, Ph. Marek wrote:
>
>>- space on harddisk - this is *currently* important! A wc with 1000 files
>> with no properties other than svn:text-time on a 4kB filesystem needs
>> 1000 * 2 * 4k ~ about 8MByte *only for this properties*!
>> Now go to a wc with 100000 files ... and 800M are gone.
You say "800M are gone" as if it's a bad thing, but if the whole WC occupies 10
GB or so then it's trivial.
>> Although matters are progressing on this front.
>
> That's quite significant. Also, files do not typically have properties
> (with the possible exception of svn:eol-style), and there's a fair amount
> of optimisation that's been done lately to improve matters in that case.
> Adding svn:text-time to all files unconditionally would probably be a
> bad idea.
You're both doing "premature optimisation". Concentrate on what would be
functionally desirable, and THEN determine if we need to make any improvementes
in efficiency, and we'll make them. Mention the inefficiency as a caveat,
don't treat it as a show-stopper.
> [Note that the FSFS format has the capability to store properties as
> deltas against earlier versions, but the implementation doesn't currently
> do that, presumably at least partly because properties are considered to
> be things that change infrequently - and so doing so probably wouldn't
> be worth the effort in terms of space saved, and would also mean it
Looks like you got your argument back to front there :-)
> would take longer to reconstruct the properties during a read.]
Premature optimisation again - unless you have measured that speed loss and
found it to be unacceptably large, which I seriously doubt.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by Julian Foad <ju...@btopenworld.com>.
Malcolm Rowe wrote:
> On Mon, Nov 28, 2005 at 09:59:06AM +0100, Ph. Marek wrote:
>
>>- space on harddisk - this is *currently* important! A wc with 1000 files
>> with no properties other than svn:text-time on a 4kB filesystem needs
>> 1000 * 2 * 4k ~ about 8MByte *only for this properties*!
>> Now go to a wc with 100000 files ... and 800M are gone.
You say "800M are gone" as if it's a bad thing, but if the whole WC occupies 10
GB or so then it's trivial.
>> Although matters are progressing on this front.
>
> That's quite significant. Also, files do not typically have properties
> (with the possible exception of svn:eol-style), and there's a fair amount
> of optimisation that's been done lately to improve matters in that case.
> Adding svn:text-time to all files unconditionally would probably be a
> bad idea.
You're both doing "premature optimisation". Concentrate on what would be
functionally desirable, and THEN determine if we need to make any improvementes
in efficiency, and we'll make them. Mention the inefficiency as a caveat,
don't treat it as a show-stopper.
> [Note that the FSFS format has the capability to store properties as
> deltas against earlier versions, but the implementation doesn't currently
> do that, presumably at least partly because properties are considered to
> be things that change infrequently - and so doing so probably wouldn't
> be worth the effort in terms of space saved, and would also mean it
Looks like you got your argument back to front there :-)
> would take longer to reconstruct the properties during a read.]
Premature optimisation again - unless you have measured that speed loss and
found it to be unacceptably large, which I seriously doubt.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Mon, 28 Nov 2005, Malcolm Rowe wrote:
> On Mon, Nov 28, 2005 at 09:59:06AM +0100, Ph. Marek wrote:
> > - space on harddisk - this is *currently* important! A wc with 1000 files
> > with no properties other than svn:text-time on a 4kB filesystem needs
> > 1000 * 2 * 4k ~ about 8MByte *only for this properties*!
> > Now go to a wc with 100000 files ... and 800M are gone.
> > Although matters are progressing on this front.
>
> That's quite significant. Also, files do not typically have properties
> (with the possible exception of svn:eol-style), and there's a fair amount
> of optimisation that's been done lately to improve matters in that case.
Just to clarify, the optimizations Malcolm seem to be talking about is
wc-propcaching. What has change is that when there are no propmods, there
is only one property file and not two per WC entry. But no properties have
been moved out from the properties file, so a single svn:eol-style="*"
will still result in one property file. That's why it is called caching:-)
As I said in another thread, storing all baseprops in one file per
directory is probably a good optimization as well - in most cases.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Mon, 28 Nov 2005, Malcolm Rowe wrote:
> On Mon, Nov 28, 2005 at 09:59:06AM +0100, Ph. Marek wrote:
> > - space on harddisk - this is *currently* important! A wc with 1000 files
> > with no properties other than svn:text-time on a 4kB filesystem needs
> > 1000 * 2 * 4k ~ about 8MByte *only for this properties*!
> > Now go to a wc with 100000 files ... and 800M are gone.
> > Although matters are progressing on this front.
>
> That's quite significant. Also, files do not typically have properties
> (with the possible exception of svn:eol-style), and there's a fair amount
> of optimisation that's been done lately to improve matters in that case.
Just to clarify, the optimizations Malcolm seem to be talking about is
wc-propcaching. What has change is that when there are no propmods, there
is only one property file and not two per WC entry. But no properties have
been moved out from the properties file, so a single svn:eol-style="*"
will still result in one property file. That's why it is called caching:-)
As I said in another thread, storing all baseprops in one file per
directory is probably a good optimization as well - in most cases.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Mon, Nov 28, 2005 at 09:59:06AM +0100, Ph. Marek wrote:
> - space on harddisk - this is *currently* important! A wc with 1000 files
> with no properties other than svn:text-time on a 4kB filesystem needs
> 1000 * 2 * 4k ~ about 8MByte *only for this properties*!
> Now go to a wc with 100000 files ... and 800M are gone.
> Although matters are progressing on this front.
That's quite significant. Also, files do not typically have properties
(with the possible exception of svn:eol-style), and there's a fair amount
of optimisation that's been done lately to improve matters in that case.
Adding svn:text-time to all files unconditionally would probably be a
bad idea.
> - with the current patches there's a chance of conflicts in the property.
> If I dig out the old version and look there this could be avoided - there
> was a special case to take the newer of two dates.
>
Conflict resolution should be specified in the design. Like Julian said,
it should be possible to infer the behaviour that's expected after any
combination of steps.
> BTW, a question just pops up in my head: if a property's name is used for many
> files, is the name in the repository just stored once, with pointers to it,
> or are there N copies?
>
I don't know about BDB, but for FSFS, there's a complete (uncompressed)
copy of the property hash stored in the rev-file whenever any of the
properties changes.
So for N files, each with M revisions, you'll have N*M copies of the
whole property hash (since we'd expect the mtime to change on each
commit).
[Note that the FSFS format has the capability to store properties as
deltas against earlier versions, but the implementation doesn't currently
do that, presumably at least partly because properties are considered to
be things that change infrequently - and so doing so probably wouldn't
be worth the effort in terms of space saved, and would also mean it
would take longer to reconstruct the properties during a read.]
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Mon, Nov 28, 2005 at 09:59:06AM +0100, Ph. Marek wrote:
> - space on harddisk - this is *currently* important! A wc with 1000 files
> with no properties other than svn:text-time on a 4kB filesystem needs
> 1000 * 2 * 4k ~ about 8MByte *only for this properties*!
> Now go to a wc with 100000 files ... and 800M are gone.
> Although matters are progressing on this front.
That's quite significant. Also, files do not typically have properties
(with the possible exception of svn:eol-style), and there's a fair amount
of optimisation that's been done lately to improve matters in that case.
Adding svn:text-time to all files unconditionally would probably be a
bad idea.
> - with the current patches there's a chance of conflicts in the property.
> If I dig out the old version and look there this could be avoided - there
> was a special case to take the newer of two dates.
>
Conflict resolution should be specified in the design. Like Julian said,
it should be possible to infer the behaviour that's expected after any
combination of steps.
> BTW, a question just pops up in my head: if a property's name is used for many
> files, is the name in the repository just stored once, with pointers to it,
> or are there N copies?
>
I don't know about BDB, but for FSFS, there's a complete (uncompressed)
copy of the property hash stored in the rev-file whenever any of the
properties changes.
So for N files, each with M revisions, you'll have N*M copies of the
whole property hash (since we'd expect the mtime to change on each
commit).
[Note that the FSFS format has the capability to store properties as
deltas against earlier versions, but the implementation doesn't currently
do that, presumably at least partly because properties are considered to
be things that change infrequently - and so doing so probably wouldn't
be worth the effort in terms of space saved, and would also mean it
would take longer to reconstruct the properties during a read.]
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Monday 28 November 2005 09:42, Jim Blandy wrote:
> It's late, so please be patient, but:
>
> Wouldn't it make sense to separate the issue of whether we record the
> file's modification time when it goes into the repository from whether
> we restore it on the way out?
>
> I'd expect that we would always want to record the modtime in the
> repository --- why throw away information?
>
> But whether we want to restore the modtime when we update depends on
> how we use modtimes in our working copy. Restoring modtimes could
> confuse 'make' pretty badly.
The problems with this approach are
- bandwidth
- space on harddisk - this is *currently* important! A wc with 1000 files
with no properties other than svn:text-time on a 4kB filesystem needs
1000 * 2 * 4k ~ about 8MByte *only for this properties*!
Now go to a wc with 100000 files ... and 800M are gone.
Although matters are progressing on this front.
- with the current patches there's a chance of conflicts in the property.
If I dig out the old version and look there this could be avoided - there
was a special case to take the newer of two dates.
And in the patches as they are the existence is the flag if it should be
restored or not ... although that could be solved with another flag-property
like "svn:special".
BTW, a question just pops up in my head: if a property's name is used for many
files, is the name in the repository just stored once, with pointers to it,
or are there N copies?
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Monday 28 November 2005 09:42, Jim Blandy wrote:
> It's late, so please be patient, but:
>
> Wouldn't it make sense to separate the issue of whether we record the
> file's modification time when it goes into the repository from whether
> we restore it on the way out?
>
> I'd expect that we would always want to record the modtime in the
> repository --- why throw away information?
>
> But whether we want to restore the modtime when we update depends on
> how we use modtimes in our working copy. Restoring modtimes could
> confuse 'make' pretty badly.
The problems with this approach are
- bandwidth
- space on harddisk - this is *currently* important! A wc with 1000 files
with no properties other than svn:text-time on a 4kB filesystem needs
1000 * 2 * 4k ~ about 8MByte *only for this properties*!
Now go to a wc with 100000 files ... and 800M are gone.
Although matters are progressing on this front.
- with the current patches there's a chance of conflicts in the property.
If I dig out the old version and look there this could be avoided - there
was a special case to take the newer of two dates.
And in the patches as they are the existence is the flag if it should be
restored or not ... although that could be solved with another flag-property
like "svn:special".
BTW, a question just pops up in my head: if a property's name is used for many
files, is the name in the repository just stored once, with pointers to it,
or are there N copies?
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by Jim Blandy <ji...@red-bean.com>.
It's late, so please be patient, but:
Wouldn't it make sense to separate the issue of whether we record the
file's modification time when it goes into the repository from whether
we restore it on the way out?
I'd expect that we would always want to record the modtime in the
repository --- why throw away information?
But whether we want to restore the modtime when we update depends on
how we use modtimes in our working copy. Restoring modtimes could
confuse 'make' pretty badly.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 27, 2005, at 19:23, Malcolm Rowe wrote:
> On Wed, Nov 23, 2005 at 07:11:45AM +0100, Ph. Marek wrote:
>
>> What is wanted?
>> - To save the (modification-) timestamp for each committed file, and
>> to restore them.
>
> It might be useful to include a brief note on why this requirement
> exists
> in the first place: what need or use case isn't being fulfilled by the
> current functionality?
People on this list are constantly going on about how a version
control system's job is to accept and archive data thrown at it, not
to change it. This is presented as an argument against many user
suggestions—for example, the ability to have a post-commit hook do
automated syntax formatting on committed source code files. The
rationale is that the system should not store a modified version of
what the user commits; it should store exactly what the user commits.
The same argument should be applied to metadata such as the
modification date.
Suppose we have a programmer Joe who can't write any decent code
before 10 AM when he has his second cup of coffee. Suppose he writes
some code before 10, some other code after 10, and commits everything
together at 11. The commit time is 11, and when checked out (with use-
commit-times on) the modification time of the files is also 11.
Suppose we are looking at the code now and wondering if it is
correct. If we could see the time at which the files were actually
modified, we would be better-able to decide which files might be
suspect.
A less-contrived example would be importing an old project into a new
repository. All files in the project will allegedly be modified at
the commit time, when in fact the project may have been last modified
years. The act of importing the project in effect deletes the history
of the project, and someone who later looks at the project will think
it's newer than it is.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 27, 2005, at 19:23, Malcolm Rowe wrote:
> On Wed, Nov 23, 2005 at 07:11:45AM +0100, Ph. Marek wrote:
>
>> What is wanted?
>> - To save the (modification-) timestamp for each committed file, and
>> to restore them.
>
> It might be useful to include a brief note on why this requirement
> exists
> in the first place: what need or use case isn't being fulfilled by the
> current functionality?
People on this list are constantly going on about how a version
control system's job is to accept and archive data thrown at it, not
to change it. This is presented as an argument against many user
suggestions—for example, the ability to have a post-commit hook do
automated syntax formatting on committed source code files. The
rationale is that the system should not store a modified version of
what the user commits; it should store exactly what the user commits.
The same argument should be applied to metadata such as the
modification date.
Suppose we have a programmer Joe who can't write any decent code
before 10 AM when he has his second cup of coffee. Suppose he writes
some code before 10, some other code after 10, and commits everything
together at 11. The commit time is 11, and when checked out (with use-
commit-times on) the modification time of the files is also 11.
Suppose we are looking at the code now and wondering if it is
correct. If we could see the time at which the files were actually
modified, we would be better-able to decide which files might be
suspect.
A less-contrived example would be importing an old project into a new
repository. All files in the project will allegedly be modified at
the commit time, when in fact the project may have been last modified
years. The act of importing the project in effect deletes the history
of the project, and someone who later looks at the project will think
it's newer than it is.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Wed, Nov 23, 2005 at 07:11:45AM +0100, Ph. Marek wrote:
> What is wanted?
> - To save the (modification-) timestamp for each committed file, and
> to restore them.
It might be useful to include a brief note on why this requirement exists
in the first place: what need or use case isn't being fulfilled by the
current functionality?
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by Julian Foad <ju...@btopenworld.com>.
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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by Jim Blandy <ji...@red-bean.com>.
It's late, so please be patient, but:
Wouldn't it make sense to separate the issue of whether we record the
file's modification time when it goes into the repository from whether
we restore it on the way out?
I'd expect that we would always want to record the modtime in the
repository --- why throw away information?
But whether we want to restore the modtime when we update depends on
how we use modtimes in our working copy. Restoring modtimes could
confuse 'make' pretty badly.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Wed, Nov 23, 2005 at 07:11:45AM +0100, Ph. Marek wrote:
> What is wanted?
> - To save the (modification-) timestamp for each committed file, and
> to restore them.
It might be useful to include a brief note on why this requirement exists
in the first place: what need or use case isn't being fulfilled by the
current functionality?
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
Posted by Julian Foad <ju...@btopenworld.com>.
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