savannah-hackers-public
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Savannah-hackers-public] Re: Arch web interface for Savannah


From: Sylvain Beucler
Subject: [Savannah-hackers-public] Re: Arch web interface for Savannah
Date: Thu, 18 Jan 2007 21:30:30 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

On Wed, Jan 17, 2007 at 11:52:29PM +0100, Stephan Peijnik wrote:
> Hello Sylvain,
> 
> I just wanted to drop you a note that I have been working on
> a possible way of having a 'neat' Arch web interface in the past 
> few days.
> 
> My idea was to create a python library which allows reading of
> Bazaar archive format files (as used by GNU Arch) and then create
> a tool which (re-)reads an archive on commit and saves all information
> a web interface would need to some sort of database (what about XML files?).
> 
> I've come as far as having a small library which is able to work its way 
> through
> an archive, find projects, branches, versions and their revisions, detect 
> settings
> (but except for printing them it doesn't handle the archive settings), read 
> the
> checksum files in each revision and extract some basic information (files and 
> checksums)
> from that file.
> 
> A sample output generated from a test script running on a test archive:
> 
> --8<--
> [debug] path is: /home/sp/archives/2007-test/
> [debug] archive name   : address@hidden
> [debug] archive version: Bazaar archive format 1 0
> [debug] settings: {}
> [debug] 3 projects found.
> a: address@hidden
>   c: test
>     b: devo
>       v: 0.1
>         r: patch-2
>                 by Stephan Peijnik <address@hidden>
>                 at Wed Jan 17 08:36:35 CET 2007
>           f: test--devo--0.1--patch-2.patches.tar.gz
>             sha1: 67b5d9d310e72c80411aa993335d1f50e1e2a1ac
>              md5: dce2046e7ad53c1ce31073988b2d0f64
>           f: log
>             sha1: 7c60b4a433f1bd11d77828690e19c6bcc4efe8a6
>              md5: 2e1b836863919ca3a085482f9dcc70a3
>         r: base-0
>                 by Stephan Peijnik <address@hidden>
>                 at Tue Jan 16 21:59:46 CET 2007
>           f: log
>             sha1: 4a863fd75939af21d3644a616cd96cefb7871cdb
>              md5: 0ae6c9fde34dcd17c504ad86c6003c72
>           f: test--devo--0.1--base-0.src.tar.gz
>             sha1: 66c4a94c1ebb52d422ea9bdbc9601d3e17a57cc7
>              md5: daff4116a8083f62814511acb112d378
>         r: patch-1
>                 by Stephan Peijnik <address@hidden>
>                 at Tue Jan 16 23:08:58 CET 2007
>           f: log
>             sha1: 1475b2383fb0b61898ac06e24936d0d98872cafc
>              md5: 38e062264b6cc8de85e6c51e49186789
>           f: test--devo--0.1--patch-1.patches.tar.gz
>             sha1: 4a2db4b9796460397678d5e1165dfe6ab268ea4b
>              md5: 4912ea4d6c2dcf3e74263c312436309f
>     b: stable
>       v: 0.1
>       v: 0.0
> -->8--
> 
> As you can see, most of the information I mentioned above is included
> in this sample output.
> 
> My next goal is to extract the files from the tarballs and handle them.
> Then, as soon as all the bits of this library are finished I'm planning
> to write a simple program which generates the above mentioned database,
> which in turn could simply be read by a PHP script or similar and produce
> the view.
> 
> What do you think about this way of solving the 'problem'?
> 
> Regards,
> 
> Stephan
> 
> PS: The library could in theory be extended to also support other 
>       a.) archive formats,
>       b.) revision control systems (SVN anyone?)

Hi,

I don't know if this solution is good, but it would be nice to
implement it and benchmark it against other solutions anyway :)

The database you suggest is partially present in revision libraries,
which is what ArchZoom uses. It takes more disk space, though the use
hard-links reduces that somewhat.

A practical problem is that Arch is serverless, which means your
script need to be ran by a client-side commit hook. Your script should
also be solid enough to detect when he wasn't run for the previous
commit (eg a new contributor to the project didn't install the hook
yet and commit w/o it).

Bonsai for CVS may be something to study btw.

As far as XML is concerned, I haven't heard of it as an efficient
storage system :/

-- 
Sylvain




reply via email to

[Prev in Thread] Current Thread [Next in Thread]