> 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
> 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'
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
> 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
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.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Jul 7 20:13:17 2005