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

Re: [PATCH] Fix issue 1037 (Repository UUIDs)

From: <mbk_at_boredom.org>
Date: 2003-01-29 21:09:03 CET

On Wed, Jan 29, 2003 at 06:55:50PM +0100, Branko ?ibej wrote:
 mark benedetto king wrote:
 
 The first record in this table is considered the
 repository's own UUID. This value is preserved across dump/load
 cycles. If one wants to load without changing the UUID, it can
 simply be removed from dump file (it is always the third line).
 
 Wouldn't it be better to pass a flag to svnadmin load to make it ignore
 that record? The dump file could be huge, which would make it a bit of a
 pain to edit it. The UUID in the dump file should be ignored during
 incremental loads, too -- or perhaps not written during incremental writes.

I was thinking more along the lines of

perl -lne 'print unless $.==3' dumpfile | svnadmin load repo

but sure, I can add an option.

 
 +/* UUID manipulation. */
 +
 +/** Populate @a *uuid with the UUID associated with @a fs.
 + *
 + * Populate @a *uuid with the UUID associated with @a fs.
 + */
 
 
 Why the repeated docstrings? If we want the brief descriptions repeated,
 we should say so in doxygen.conf (the REPEAT_BRIEF option). It's
 currently set to NO.
 

I must confess that I tried to simply intuit what the docstrings
should be from looking at others in the code. I was not aware of
the REPEAT_BRIEF option. However, and this probably further
illustrates my ignorance, wouldn't turning *off* REPEAT_BRIEF
*necessitate* repeating the docstrings? My assumption has been
that the first one shows up somewhere as the short description
and the second one shows up somewhere else as the long description.

 Apart from that, the patch looks complete to my short-sighted eyes.
 

Well, I found out this morning that it makes make check really
unhappy, so it probably needs some work somewhere. :-)

--ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:24:17 2006

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.