handling zip files

[hamann.w at t-online.de]

>> 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