Hi Martin,
The task mentioned in my point 4 of the previous message (see below)
could be solved in the following way.
Assume we have a (nightly built) distribution tarball which
was last time generated shortly after midnight of 2011-08-11,
and it was then called
openxpki-deployment-2011-08-11.tar.gz
Assume that today comes a new day of 2011-09-12.
Shortly after midnight we start automatic script
(which is called "generate-last-midnight.sh" if you do not know this).
It should work as follows.
1) We update a local clone (or snapshot - whichever you like),
go to the directory ..../openxpki/trunk/deployment
and (using "find" and "ls" unix tools) obtain a date (and maybe time)
of the last modification of files under this directory.
2) If this date-time falls earlier than midnight of 2011-08-11
(this date is deduced from the previous tarball
openxpki-deployment-2011-08-11.tar.gz
which is kept nearby for reference of this kind),
then we do nothing. Because we already have the latest possible tarball.
If this date-time falls equal or later than midnight of 2011-08-11,
then we generate a new tarball and name it as
openxpki-deployment-2011-09-12.tar.gz
3) Thus we escape any need of svn or git or god-knows-which versioning
mechanism.
And the website can honestly say that nighty buit tarball
openxpki-deployment-2011-09-12.tar.gz
is the latest possible tarball based on the most fresh code.
Adjusting of our script to this mechanism is easy.
What do you think of the idea?
All the best, Sergei
On 21.08.2011 22:51, Sergei Vyshenski wrote:
> Hi Martin,
>
> On 17.08.2011 19:49, Martin Bartosch wrote:
>> As mentioned, I think simply installing git might already help.
>
> No. I installed git (version 1.7.5.1 from FreeBSD ports) with svn
> support enabled. This does not solve the main problem here:
>
> 1. Vergen complains about missing executable called git-svn. I had to
> add an executable file with this name on a path with content:
>
> #!/bin/sh
> git svn $@
>
> to silence complains from vergen. Correct?
>
> 2. Vergen still refuses to work from within a regular svn snapshot.
> Despite its "man" which claims it should.
> (Vergen is triggered during intermediate stage of installing tarballs,
> which is needed to generate proper FreeBSD ports.)
> It says:
>
> Could not determine value for mandatory component 'git-filtered-branch'.
> Stopped at ../../../../tools/vergen line 379
>
> 3. As for work from within git clone, I failed to find a git (or vergen
> based) analog for:
>
> svn info | grep -e "Last Changed Rev" | awk '{ print $4 }'
>
> And vergen always gives only the last common version (if called from
> within any part of the git clone) which today has number 1568.
>
> 4. We need a versioning mechanism as follows:
>
> A distribution tarball gets a new version then (and only then) when
> something related to this particular tarball changes.
> Recall, we have 6 different tarballs.
> Also we have 6 different FreeBSD ports matched to corresponding tarballs.
> It would be too strange and counter intuitive and time-resource consuming
> (with rebuilding and reinstalling of all 6) to bump the versions of
> _all_ tarballs and ports after committing a change related to only one
> of them.
>
> Could you please recommend a mechanism for such a versioning.
>
> All the best, Sergei
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> OpenXPKI-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openxpki-devel
------------------------------------------------------------------------------
Doing More with Less: The Next Generation Virtual Desktop
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops? How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
_______________________________________________
OpenXPKI-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-devel
