[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed

From: Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
Date: 2005-11-28 10:36:59 CET

I would want the modification time stored for every revision.

Would this property be stored within the Berkley DB? If so then wouldn't
this be compressed like the rest of the database? - on my project the
files when exported are approx 500Mb and the repository size on the
initial import was 139Mb, thus it must have been compressed.

If space is an issue then adding a configuration option to only store
the latest modification time would solve this.

As a general rule it is always worth storing the information by default
and then letting the user specify that they do not want it stored.


-----Original Message-----
From: Ph. Marek [mailto:philipp.marek@bmlv.gv.at]
Sent: 28 November 2005 08:59
To: Jim Blandy
Cc: users@subversion.tigris.org; Mark Phippard;
Subject: Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed

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
  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
  If I dig out the old version and look there this could be avoided -
  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?



To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 28 10:42:20 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.