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

Re: [PATCH] svnadmin copy command(Scanned for viruses: Notes Admin)

From: <vberezniker_at_siuh.edu>
Date: 2003-07-31 23:26:47 CEST

Sorry, forgot to include change log:

Add ability to list all Berkley DB log files not only the unused ones.

* svnadmin/main.c
       Add --all-logs option to svnadmin archive command

* include/svn_fs.h
        (svn_fs_berkeley_archive): Change return pointer to
apr_array_header_t type from pointer to NULL-terminated array of const
char *. Add parameter specifying whether to return relative paths or
absolute paths. Add parameter specifying whether to return all or only
unused log file names.

* libsvn_fs/fs.c
        (svn_fs_berkeley_archive): Implement function as specified in
include/svn_fs.h.

Sincerely,
Vladimir Berezniker

Vladimir Berezniker
07/31/2003 05:03 PM

        To: dev@subversion.tigris.org
        cc: (bcc: Vladimir Berezniker/SIUH)
        Subject: Re: [PATCH] svnadmin copy command

Please find svnadmin archive patch without the parameter for log file name
only. However, the option can still be set programmatically when calling
svn_fs_berkeley_archive().

Sincerely,
Vladimir Berezniker

Vladimir Berezniker
07/31/2003 12:56 PM

        To: cmpilato@collab.net
        cc: dev@subversion.tigris.org
        Subject: Re: [PATCH] svnadmin copy command

Here is my logic. There are two ways the function can be used. First is
by outside tool that calls svnadmin archive. In this case absolute path
is *the* way, as the tool should not need to know anything about the
repository layout. However, in cases when a manipulation is done by
subversion internals that are aware of the repository structure and needs
to compare logs files between two repositories, then the relative path
would be useful.

In case of my proposed svnadmin copy command when unused log deletion is
requested, I use the following algorithm:

1. Make a copy of everything but /db area.
2. Copy all tables
3. Copy all logs
4. Get a list of unused logs in the source repository.
5. Iterate over unused log list
5a.If log exists at the destination and is the same file, then delete the
log at source

At step 3 absolute log path can be used to make a copy. However, at step
5a since I need to check log file name at two different repositories it is
easier to use log file name only and append it to a "db" paths within each
repository.

Logical question I expect here is why not delete all unused log files from
source and be done with it, as hot-backup.py does?

I have a concern about unconditionally deleting unused log files in the
source repository. Imagine the following scenario:
While logs a being copied (step 3) there is repository activity that
causes the latest log to go from used to the unused state (e.g. reached
maximum size limit). If at (step 5) we just delete unused logs we would
delete a log that was not copied fully.

Please correct me if I am overlooking something.

Sincerely,
Vladimir Berezniker

<cmpilato@collab.net>
Sent by: cmpilato@localhost.localdomain
07/31/2003 12:05 PM
Please respond to cmpilato
 
        To: <vberezniker@siuh.edu>
        cc: dev@subversion.tigris.org
        Subject: Re: [PATCH] svnadmin copy command(Scanned for
viruses: Notes Admin)

<vberezniker@siuh.edu> writes:

> For starters I would like to submit a patch to libsvn_fs's
> svn_fs_berkeley_archive() functionality.
>
> First is to change the return type of a function from Berkeley DBs
pointer
> list to apr array (apr_array_header_t). Add a new parameter allowing to

> receive only log file names without the absolute path and a parameter
that
> would include used log files in the list.

I don't really see the need to have the abs-vs.-rel path parameter. I
mean, can we not do the right thing with both? The second parameter,
yes, we need that.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Received on Thu Jul 31 23:30:50 2003

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.