handling zip files

[Steve Barnes]

On 15/12/13 14:33, hamann.w at t-online.de wrote:
>>> IMHO the one type of binary file that it almost never makes sense to
>>> track is a .zip file - track the contents and generate the .zip file on
>>> the fly either using pythons zipfile module or using one of the command
>>> line zip file tools.
>>>
>>> Gadget/Steve
> Hi Steve,
>
> the problem is that the application designers chose to use non-text files as there storage format,
> so opening / saving the application file internally unpacks resp. creates a zip. This is similar to
> openoffice, and the analogy goes even further ... most of the zip members happen to be xml
>
> Normal use of the file is opening / modifying / saving it with its proper application, and while it would
> be possible to create a specialized version of open-source tools like OO or add a wrapper
> to closed-source tools, fellow users expect to see the native file format
>
> So if there was a way for mercurial to handle the unzipping transparently, it would help
> quite a lot because it would not disrupt the workflow. I would sort of expect the inner workings to be
> built on zipfile ...
>
> Regards
> Wolfgang
>
>
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
>
Hi Wolfgang,

I would consider having a hidden directory of a name derived from the 
actual name of the .zip file that contains the content, (mostly xml), 
and possibly a list of the files or a wildcard that specified which 
files to process, have a `precommit` hook that before the commit is 
generated unzips the content of the file(s) following the structure 
within the zip, over the existing directory structure and ensures that 
they are all 'added' to the repository.  Your .zip format files would be 
marked as ignored and the rest of the repository committed.

You will probably need to also invoke this same hook as a `preupdate` 
hook so that if the users have made any changes they are in the 
directory structure.

Then have an `update` hook|| that zips the content of the 
directory/directories back into the application files.

Committing, pushing, pulling and updating could easily be wrapped into a 
simplified user interface so that the users don't even know that they 
are using Mercurial.

Hope that has given you some ideas - the reference for hooks is here 
<http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html>.

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20131215/a39254cb/attachment-0002.html>