handling zip files

[Steve Barnes]

On 20/12/13 05:28, hamann.w at t-online.de wrote:
>>> 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
>>>>
>>>>
>>>>
>>> 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>.
>>>
>
> Hi Steve,
>
> thanks for the pointers.
> As I have already set up an external tool that uses linux inotify to watch relevant
> folders, I have added
> rm -rf <file_without_extension>
> unzip -d <file_without_extension> file
> hg addremove <file_without_extension>
> to the recipe.
>
> Another question: is there a way to trigger an external program when somthing
> is added to the repo
>
> Regards
> Wolfgang
>
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
>
Hi Wolfgang,

Since you are already detecting changes above I would guess that you 
mean that the external repository has changed and you have pulled those 
changes to your local repository - this would not actually change the 
local files until you run an update - so adding an update hook would 
trigger your action(s).

Steve