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

[TSVN] Re: Changing location of stored commit messages

From: Valik <vampire.valik_at_gmail.com>
Date: 2005-07-07 20:59:31 CEST

> -----Original Message-----
> From: SteveKing [mailto:steveking@gmx.ch]
> Posted At: Thursday, July 07, 2005 2:13 PM
> Posted To: gmane.comp.version-control.subversion.tortoisesvn.devel
> Conversation: Changing location of stored commit messages
> Subject: Re: Changing location of stored commit messages
>
> Valik wrote:
>
> > I like the idea of storing previous commit messages, but I don't
like
> > the location they are stored in. Doing a large number of commits or
> > committing with long messages will cause an unnecessary increase in
> > the size of the registry hive(s). Making the registry larger will
in
> > turn begin to affect overall system performance since there will be
> > more stuff to process when applications access the registry.
>
> Do you have any problems because of this? Or is this just a rhetorical
> issue?

At the moment, it's purely rhetorical. However, I know how much I
despise it when applications abuse the registry by storing things that
don't belong there. It's even worse when applications leave things
behind. All these things contribute to a bloated registry. I'm not
accusing TSVN of this of course, I'm just stating that in general, there
is already a lot of crap and intentionally putting more stuff just
compounds the issue.

>
> > My suggestion is to use a specially formatted file stored on disk to
> > hold the data. Storing on disk will not bloat the registry. Even
> > Microsoft states on MSDN that things should be stored on disk with
> > just a path stored in the registry instead of storing the contents
of
> > the file directly in the registry.
>
> MS states that 'big' amounts of data shouldn't be stored in the
> registry. They don't give an estimate about what they mean with 'big'
> though.
> Storing things like log messages in the registry is completely valid.
> The strings in a log message aren't that big (of course, if you write
> log messages which are 100kBytes big, you might get a big registry
hive,
> but then I would suggest to rethink your log message policy instead of
> changing TSVN).

A lot of small commit messages are just as potent as a few large
commits. Also, I believe strings stored in the registry are stored as
Unicode, so that right there doubles the size automatically.

> > The actual storage format or location doesn't matter. I can see INI
> > or XML files being used in conjunction with either a profile
specific
> > location (%APPDATA%) or a public location with the correct file
> > pointed to by a string in HKEY_CURRENT_USER.
>
> INI files don't work, because
> - they're limited to 64k
> - strings in an ini file are limited to ~250 chars
>

I forgot about the Windows 95/98 INI limits. Also, there is a
per-section limit of 32768 on Windows 95 and possibly 98 (Although I
don't believe TSVN supports 95 so that's moot). An INI won't work
anyway without some processing to transform CR and LF into something for
storage since INI files are line-based. So forget the INI idea.

> Sure, we could store them in an xml file. But why bother? I mean that
> would be a lot of work, for something no one has had problems before.
>
> Stefan

XML would also add more "bloat" with the text used for its tags and
such. It was only a suggestion, anyway. I think the most realistic
solution and also the most simple to implement would be a custom file
format. I think a NULL delimited double-NULL terminated file would be
sufficient for storage. Store the files in a directory such as
"%APPDATA%\TortoiseSVN\History\" with the file named after the UUID of
the repository. That's very similar to what's done now with the
registry.

Keep in mind, too, that just because nobody has had problems before
don't mean they won't. I don't think the custom-format idea is so
radical that implementing it would cause regressions like switching to
XML might. Also the custom-format isn't very much work. The code for
that can be written off the top of one's head provided they don't
already have code lying about to split a string by a delimiter.

- Valik

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Jul 7 21:08:18 2005

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

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