RE: Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
"Thompson, Graeme (AELE)" <[email protected]> Mon, 28 Nov 2005 02:36:59 -0700
| Newsgroups | gmane.comp.version-control.subversion.devel,gmane.mail.eyebrowse.user |
|---|---|
| Message-ID | <75B09A482EAF344599A0C14109EA59A901A66025__41459.4705369838$1133171001$gmane$org@COSSMGMBX04.EMAIL.CORP.TLD> |
Storage: 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. Graeme -----Original Message----- From: Ph. Marek [mailto:[email protected]] Sent: 28 November 2005 08:59 To: Jim Blandy Cc: [email protected]; Mark Phippard; [email protected] 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 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: [email protected] For additional commands, e-mail: [email protected] ****************************************** 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. ******************************************