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

2 key features - can they be implemented or does anyone know a workaround

From: Jay Crouch <jay_at_safestream.com>
Date: 2007-08-16 03:02:39 CEST

To Subversion developers:

My company is using SVN to implement a Œweb based remote file system¹,
complete with ACL and version tracking.

We have run into a problem that I think requires a couple features to be
added to the SVN project ­ so I¹m hoping you all can tell me if this could
be incorporated into the next release or if there is another (quick) method.

1: Is there any way to upgrade the SVN command line utility to add an option
like -f (for Force) to each of the following commands: copy, move, import.
The option would cause the deletion the destination target prior to
performing the operation in the case of copy & move and basically simulate a
check in for the case of import. ***Import is the big one here for us.***

2: Is there any kind of batch mode utility available (and if not, could one
be created) that would allow us to chain multiple svn command line
statements together, resulting in only a single revision increment upon
completion of the sequence?

I'm thinking something like the following:
Svnbatch
Svn copy URL URL
Svn copy URL URL
Svn delete URL
Svn copy URL URL

The reasons for both these questions follow. Thanks again for your
consideration.

Thank you for any assistance.

Jay

Context:

At first we were very interested in using SVN+WEBDAV to implement our file
system since it already had the advanced apache features built in ... But in
the end we had to home grow our own solution due to lack of repo path ACL
support.

Since dev time is of essence to us, we are using a very simple PHP wrapper
class that is issuing system calls to SVN over the command line [ note, this
is not to say we¹re using a custom PHP extension with C headers].

To minimize disk space, we¹re not using any working copies ­ just
repositories, so all SVN statements are issued on file based URLs.

For example, when our service receives a request to copy a path, the web
service generates a system statement like the following and executes it:

³svn copy Œfile:///mnt/data/repos/146/<path_to_target>¹
Œfile:///mnt/data/repos/146/<path_to_destination>¹ ³

Or for an upload:

³svn import Œ<local_path_to_target>¹
Œfile:///mnt/data/repos/146/<path_to_destination>¹ ³

Problem Description:

This approach is working like a charm except for 2 things.

1: SVN copy, move & import command line statements currently require the
destination target to be Œempty¹, which means we are having to delete the
destination target if it exists before issuing the copy, move or import.

Deleting is easy to do, but breaks versioning ­ meaning although we
technically have all versions of targets, the system really has no way to
allow users to retrieve anything but the head version because each version
chain is a max of 1 version long (confirmed using svn log). This also means
that no deltas are being used - so each upload (import) is resulting in a
whole new file written to FS. Deleting also increases the revision numbers
unnecessarily ‹ see problem #2.

2: Each copy, move, import, delete & rename statement run via the command
line is generating a new revision. This is fine except when we are
attempting to perform an operation over multiple targets... In our system we
have to loop over each target generating a system call for each, meaning if
a user selects 3 files (or directories) to copy, by the time the operation
is copied the version # has increased by 3 to 6 (depending if destination
targets had to be deleted first).

Thanks, MUCH

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 16 22:40:45 2007

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.