> It works. I am not 100% happy with the implementation,
> but it is good enough to be used in practice (it is
> used in production at my workplace). Here is a list of
> issues with the current implementation:
> -- the generated diff includes only the changes, it
> does not include the added or deleted files.
> What to do with those?
deleted files can be listed (as of current wine-cvs)
for added files you can add on the CGI the full content of
the file (of its diff against /dev/null)
> -- the CGI program must reside on the CVS machine
> as it needs access to the commit log; the name
> of the machine gets hardcoded in the commit
> log entry.
> Not a big deal in Wine's case I think, as
> cvs.winehq.com is not likely to change.
you could also run it on a local cvs tree (using cvsup or
rsync to keep it updated)
> -- the program does a linear scan of the commit log,
> so in the long term, we can have problems.
> I would like to have each log message saved in
> a file in some sort of directory structure
> (I was considering:
> commitlog.d/<year>/<week of year>/<id of msg>)
> That would be much better and I would be happy
> to implement it if no one objects to it.
well, we could also link this to the wine version numbers...
we could this way rebuild a page (or maintain a page) for
all the changes to a given versio
> My questions are:
> -- do you guys agree that it would be cool to have
> such a thing for the Wine repository
yup
> -- if so, what would it take to implement these
> features in our repository
get back to me, i'll check on the winehq-admin team
anyway, here are a couple of questions:
- how to you (plan to) handle a patch that is reverted ?
A+
--
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
