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

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

From: Ph. Marek <philipp.marek_at_bmlv.gv.at>
Date: 2005-11-28 09:59:06 CET

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?



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:03:14 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.