Hi,

I would like darcs to be able to look „inside“ gzip and tar files (and others
possible as well). The motivation are file formats like .odt that are zip-files
that contain plain text (here: xml) files, or formats like zipped svg as used by
inkscape. If darcs would be able to unpack these and actually record the change
of the contents as a patch, it could merge independent edits of the same
document or image, just as it could merge them when they were not wrapped.

As this is of course not always desired, this could be enabled with a flag when
adding the file first and the file be marked approriately, similar to binary
files are flagged. From then on, darcs could transparently uncompress and
compress the .gzip file when modifiying them, or treat the zip file similar to a
directory.

I have not heard of any other VCS that implements this, but I think it’s a very
useful feature that darcs could shine with.

Greetings,
Joachim

Could this be accomplished by clever use of pre and post hooks?

Hi,

Am Freitag, den 27.06.2008, 12:42 +0000 schrieb Eric Kow:
> Could this be accomplished by clever use of pre and post hooks?

possible, but tricky, and then the pre- and post-hooks would have to be
distributed somehow with the repository to all other users.

Greetings,
Joachim

On Fri, Jun 27, 2008 at 5:28 AM, Joachim Breitner <bugs@darcs.net> wrote:

>
> New submission from Joachim Breitner <mail@joachim-breitner.de>:
>
> Hi,
>
> I would like darcs to be able to look „inside" gzip and tar files (and
> others
> possible as well). The motivation are file formats like .odt that are
> zip-files
> that contain plain text (here: xml) files, or formats like zipped svg as
> used by
> inkscape. If darcs would be able to unpack these and actually record the
> change
> of the contents as a patch, it could merge independent edits of the same
> document or image, just as it could merge them when they were not wrapped.

This could work well for some people, but in general this is probably
undesirable.  The reason being is that it is usually the wrong thing for a
distributed version control tool to version files that are not directly
edited by a human.  What do you do when you have conflicts?  This isn't such
a big deal with a centeralized version control tool because those usually
support a mechanism for locking a file thus making conflicts harder to
create.

I realize that with an xml file that some users would consider it human
editable, but not all users.  Perhaps your suggestion to make this an
optional feature is a good way to avoid forcing this on users that are not
prepared to handle the consequences.

Jason

Attachments

• unnamed

I can see how this sort of thing would be helpful.

I suppose we would be storing the file in its text form in pristine and only
(un)compressing when dealing with working.

Given the combination of lots of work, unknowns, and corner-case use, I vote we
  defer this until we've met other darcs objectives such as issue1149 (libdarcs)
and the performance stuff.

Before starting work on this, I would suggest a UI mockup.  For example, should
we have an 'archives' file mechanism like binaries and boring?  I guess such a
file would associate regular expressions over file paths with archiving and
de-archiving programs.

Also another thing to consider is tar files of directories (on MacOS X,
OmniGraffle stores directories with XML files and a zip file)

For those who can't wait for Darcs to grow such a feature, see Max
Battcher's musdex:
http://blog.worldmaker.net/2010/mar/03/storing-documents-version-control-musdex/

I've taken the liberty of making Max nosy on this ticket.