Hi Sergei, > 1) vergen related, > 1) no idea,
I have some local changes which I will soon check in. Need to test it first with our package builds. With these changes vergen to no longer requires svn and emulates its behaviour. It's also possible to obtain an emulated release number (similar to the svn revision number) based on the commit distance to a reference tag. So I guess this is the easy part. > 2) web site update script,2) recall, the script is not that trivial. It grabs > data from openxpki > SVN, from openca CVS, and intermixes it in a weird way. We failed to > provide one universal script for every mirror. The committed script as in: > > http://www7.openxpki.org/svn/openxpki/www.openxpki.org/trunk/update_www_openxpki_org?op=file&rev=0&sc=0 > > had to be tuned by every mirror master by himself due to peculiarities > of his host system. Thus it became a matter of endless mailing about > fixing of mutual inconsistencies between mirrors. > > Do you have a new prototype? How about moving the website to the SourceForge web hosting service? If I remember correctly one of the main reason for us to distribute the web site on several mirrors was that the SF infrastructure was a bit flaky and unreliable in 2006. They also didn't have load balancing. This has dramatically changed in the meantime, SF provides some serious website hosting and I could imagine making use of this. I guess it would be possible to write an update script that works properly on the SF web infrastructure so we don't have to worry about keeping all mirror scripts in sync feature-wise. However, the current mirrors have problems as well, all of them need to be administrated, and we have had more than one occasion with incorrect local mirror data (e. g. OpenCA docs). If a mirror goes down, 1/nth of the website requests are not served. SF now has a redundant web server infrastructure with load balancers, sounds a bit better to me. I don't really remember if there were additional reasons that kept us from using the SF hosting, such as export restrictions or legal restrictions. If this is a problem, we should possibly keep the mirror infrastructure. > 3) nightly builds of distribution tarballs for the OpenXPKI project, > 3) and 4) could be re-handcrafted by me and Julia if necessary, I think this would require some work on your side, but it should not be too difficult (I hope). The build process could stay the same, only the repo update mechanism needs to be updated (basically exchange "svn update" with "git pull"). > 5) substitute ViewVC of the SVN repo hosted at SF, accessible via > http://www.openxpki.org/resources/index.html > 6) substitute WebSVN of the SVN repo hosted at www7, accessible via > http://www.openxpki.org/resources/index.html. > 5) Git system of SF has built-in minimalistic web viewer called "Git > Browse": > > http://openxpki.git.sourceforge.net/git/gitweb.cgi?p=openxpki/openxpki;a=summary > > which is similar to ViewVC web viewer of SF's SVN. Good. Yep, I think this is good enough. I don't use it regularly, though (I mostly use the command line tools). > 6) Do you know a tool for Git, which is similar to WebSVN viewer, with > its useful ability to show colorfully painted differences between > selected versions of the same document? In WebSVN this functionality is > called "Compare with Previous". If no, this point could be neglected? With git you have the full repo on your local system, so you can offload such things to your own workstation. There are some nice client side tools: have a look at qgit, gitk or gitg. On Mac OS I am quite a fan of GitX. But what I use most of the time are the built-in tools, such as git show-branch, git log, git diff and sometimes tig, a text only viewer. cheers Martin ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ OpenXPKI-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-devel
