You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Noorul Islam K M <no...@collab.net> on 2010/07/14 13:53:19 UTC

Issue #3645: Create directly compressed archives

Hello all,

I am planning to implement the requirement mentioned in issue
http://subversion.tigris.org/issues/show_bug.cgi?id=3645. I hope no one
has yet started on this.

I am going to add an option "--archive" to export command. If specified,
the output of the export command will be in tar format. which will be
dumped to STDOUT. The user can pipe it to any other program thereafter.

For a user it will be like this.

$ svn export . --archive > /tmp/export.tar

or 

$ svn export . --archive | bzip2 > /tmp/export.tat.bz2


Any valuable inputs will be helpful.

Thanks and Regards
Noorul

Re: Issue #3645: Create directly compressed archives

Posted by Philip Martin <ph...@wandisco.com>.
Mark Phippard <ma...@gmail.com> writes:

> On Wed, Jul 14, 2010 at 10:34 AM, Hyrum K. Wright
> <hy...@mail.utexas.edu> wrote:
>> On Wed, Jul 14, 2010 at 2:53 PM, Noorul Islam K M <no...@collab.net> wrote:
>>>
>>> I am going to add an option "--archive" to export command. If specified,
>>> the output of the export command will be in tar format. which will be
>>> dumped to STDOUT. The user can pipe it to any other program thereafter.

I suppose you intend to implement POSIX ustar?  We had problems in the
past with own tarballs when the different machines had different tar
implementations.

> My main concern is that git tends to not care too much about Windows,
> and for us it is the primary OS that is used.  So I am a little uneasy
> about having a command that only outputs a Unix file format.

If we add tar support I expect that Windows users will want untar
support as well.  They will then expect it to work with all tarballs
not just Subversion ones.  Really they would want zip, or perhaps 7z,
support.

-- 
Philip

Re: Issue #3645: Create directly compressed archives

Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Jul 14, 2010 at 10:34 AM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> On Wed, Jul 14, 2010 at 2:53 PM, Noorul Islam K M <no...@collab.net> wrote:
>>
>> Hello all,
>>
>> I am planning to implement the requirement mentioned in issue
>> http://subversion.tigris.org/issues/show_bug.cgi?id=3645. I hope no one
>> has yet started on this.
>>
>> I am going to add an option "--archive" to export command. If specified,
>> the output of the export command will be in tar format. which will be
>> dumped to STDOUT. The user can pipe it to any other program thereafter.
>>
>> For a user it will be like this.
>>
>> $ svn export . --archive > /tmp/export.tar
>>
>> or
>>
>> $ svn export . --archive | bzip2 > /tmp/export.tat.bz2
>>
>>
>> Any valuable inputs will be helpful.
>
> I think issue #3645 is about compressing the backend storage, rather
> than some output of the svn client command.  The latter can be
> accomplished fairly easily using a number of existing tools, and it's
> pretty doubtful such would be included in Subversion itself.  Also,
> just because an issue exists does not mean that the concept included
> therein has been vetted and approved for eventual inclusion.

The issue is clearly about the output of the client command and raises
a fair point as to its value.  Apparently git has the same sort of
command option.

My main concern is that git tends to not care too much about Windows,
and for us it is the primary OS that is used.  So I am a little uneasy
about having a command that only outputs a Unix file format.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Issue #3645: Create directly compressed archives

Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Wed, Jul 14, 2010 at 3:52 PM, C. Michael Pilato <cm...@collab.net> wrote:
> On 07/14/2010 10:34 AM, Hyrum K. Wright wrote:
>> On Wed, Jul 14, 2010 at 2:53 PM, Noorul Islam K M <no...@collab.net> wrote:
>>>
>>> Hello all,
>>>
>>> I am planning to implement the requirement mentioned in issue
>>> http://subversion.tigris.org/issues/show_bug.cgi?id=3645. I hope no one
>>> has yet started on this.
>>>
>>> I am going to add an option "--archive" to export command. If specified,
>>> the output of the export command will be in tar format. which will be
>>> dumped to STDOUT. The user can pipe it to any other program thereafter.
>>>
>>> For a user it will be like this.
>>>
>>> $ svn export . --archive > /tmp/export.tar
>>>
>>> or
>>>
>>> $ svn export . --archive | bzip2 > /tmp/export.tat.bz2
>>>
>>>
>>> Any valuable inputs will be helpful.
>>
>> I think issue #3645 is about compressing the backend storage, rather
>> than some output of the svn client command.
>
> Not sure what leads you to believe this.  If you read the issue, you can
> clearly see that it discusses 'git archive' (which is a tree export
> mechanism, not a repository compression tool) and compares such with 'svn
> export' as the lesser-but-at-least-somewhat-viable workaround.

A sloppy reading of the issue, and a less-than-perfect knowledge of
git, led me to believe the above.

> That said, I too am less than thrilled about adding what amounts to Yet
> Another Implementation Of the Tar Archive Algorithm to our codebase, and
> still more disappointed to think that the minute we do this the Windows
> users will be clamoring for Zip or 7z or something else.
>
> I've closed issue 3645 as WONTFIX with a similar explanation (and a
> recommended alternative feature that would be more generally useful).

+1.  The idea of 'svn export --xml' is intriguing to me, and I've
discovered issue 2538 which mentions just such a feature.

-Hyrum

Re: Issue #3645: Create directly compressed archives

Posted by Philipp Marek <ph...@linbit.com>.
On Wednesday 14 July 2010, Noorul Islam K M wrote:
> For a user it will be like this.
> 
> $ svn export . --archive > /tmp/export.tar
> 
> or
> 
> $ svn export . --archive | bzip2 > /tmp/export.tat.bz2
> 
> 
> Any valuable inputs will be helpful.
That seems to be done already - http://svn.borg.ch/svntar/:

  svntar is a program to create tar files from a
  subversion working copy or repository.
    * Creates USTAR files (filenames up to 253 characters).
    * Supports compression using gzip (-z) bzip2 (-j) and lzma (-l).
    * Permissions owner group and mtime are stored if the properties
      defined by FSVS are set.
    * Supports character and block devices created by FSVS (from
      repos URL only).


Regards,

Phil

Re: Issue #3645: Create directly compressed archives

Posted by Stefan Sperling <st...@elego.de>.
On Wed, Jul 14, 2010 at 10:52:00AM -0400, C. Michael Pilato wrote:
> That said, I too am less than thrilled about adding what amounts to Yet
> Another Implementation Of the Tar Archive Algorithm to our codebase, and
> still more disappointed to think that the minute we do this the Windows
> users will be clamoring for Zip or 7z or something else.
> 
> I've closed issue 3645 as WONTFIX with a similar explanation (and a
> recommended alternative feature that would be more generally useful).

+1

We do have code which duplicates functionality of other tools,
such as svn diff and svn patch.  But those have added value over
the standard tools. I don't see any added value in having built-in
archiving functionality in svn export, because its output can already
be archived. And it's not hard to write a small shell function or script
or Makefile snippet that automates this task.

Stefan

Re: Issue #3645: Create directly compressed archives

Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/14/2010 10:34 AM, Hyrum K. Wright wrote:
> On Wed, Jul 14, 2010 at 2:53 PM, Noorul Islam K M <no...@collab.net> wrote:
>>
>> Hello all,
>>
>> I am planning to implement the requirement mentioned in issue
>> http://subversion.tigris.org/issues/show_bug.cgi?id=3645. I hope no one
>> has yet started on this.
>>
>> I am going to add an option "--archive" to export command. If specified,
>> the output of the export command will be in tar format. which will be
>> dumped to STDOUT. The user can pipe it to any other program thereafter.
>>
>> For a user it will be like this.
>>
>> $ svn export . --archive > /tmp/export.tar
>>
>> or
>>
>> $ svn export . --archive | bzip2 > /tmp/export.tat.bz2
>>
>>
>> Any valuable inputs will be helpful.
> 
> I think issue #3645 is about compressing the backend storage, rather
> than some output of the svn client command.

Not sure what leads you to believe this.  If you read the issue, you can
clearly see that it discusses 'git archive' (which is a tree export
mechanism, not a repository compression tool) and compares such with 'svn
export' as the lesser-but-at-least-somewhat-viable workaround.

That said, I too am less than thrilled about adding what amounts to Yet
Another Implementation Of the Tar Archive Algorithm to our codebase, and
still more disappointed to think that the minute we do this the Windows
users will be clamoring for Zip or 7z or something else.

I've closed issue 3645 as WONTFIX with a similar explanation (and a
recommended alternative feature that would be more generally useful).

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Re: Issue #3645: Create directly compressed archives

Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Wed, Jul 14, 2010 at 2:53 PM, Noorul Islam K M <no...@collab.net> wrote:
>
> Hello all,
>
> I am planning to implement the requirement mentioned in issue
> http://subversion.tigris.org/issues/show_bug.cgi?id=3645. I hope no one
> has yet started on this.
>
> I am going to add an option "--archive" to export command. If specified,
> the output of the export command will be in tar format. which will be
> dumped to STDOUT. The user can pipe it to any other program thereafter.
>
> For a user it will be like this.
>
> $ svn export . --archive > /tmp/export.tar
>
> or
>
> $ svn export . --archive | bzip2 > /tmp/export.tat.bz2
>
>
> Any valuable inputs will be helpful.

I think issue #3645 is about compressing the backend storage, rather
than some output of the svn client command.  The latter can be
accomplished fairly easily using a number of existing tools, and it's
pretty doubtful such would be included in Subversion itself.  Also,
just because an issue exists does not mean that the concept included
therein has been vetted and approved for eventual inclusion.

(This is, of course, my own opinion.  Others may feel different, and
if you feel strongly about this use case, I encourage you to present
the compelling argument in favor of this feature.)

Best,
-Hyrum