* David Sowder (Zothar) <freenet-devl at david.sowder.com> [2006-05-11
10:29:04]:
> Florent Daigni?re (NextGen$) wrote:
> >* David Sowder (Zothar) <freenet-devl at david.sowder.com> [2006-05-11
> >00:12:12]:
> >
> >
> >>David Sowder (Zothar) wrote:
> >>
> >>>zothar at freenetproject.org wrote:
> >>>
> >>>>Author: zothar
> >>>>Date: 2006-05-11 04:24:24 +0000 (Thu, 11 May 2006)
> >>>>New Revision: 8652
> >>>>
> >>>>Modified:
> >>>> trunk/freenet/src/freenet/io/NetworkInterface.java
> >>>> trunk/freenet/src/freenet/io/comm/Peer.java
> >>>> trunk/freenet/src/freenet/node/FNPPacketMangler.java
> >>>> trunk/freenet/src/freenet/node/Node.java
> >>>> trunk/freenet/src/freenet/node/PeerNode.java
> >>>>Log:
> >>>>When no IP addresses are available for handshake, reset the handshake
> >>>>timer. Only do DNS lookups during handshake and store the result.
> >>>>Explicitly set Java's negative DNS cache TTL. Factored out the
> >>>>repeated use of some address lookup methods within a few lines of
> >>>>each other. Fixed an NPE caused by trying to call the canGetCipher()
> >>>>method on a null DHContext. Added another short-circuit to
> >>>>getHandshakeIPs().
> >>>>
> >>>>
> >>>To whomever is in charge of the FreenetLogBot related auto-builder,
> >>>the SVN revision of 8652 seems to be properly displayed everywhere but
> >>>on the running node, which still thinks it's on r8649 (the changes
> >>>otherwise are in the newly built and downloaded version). Maybe this
> >>>problem is related to the Eclipse substitution question (dunno if the
> >>>auto-builder uses it)?
> >>>
> >>Ah, this is because the keyword substitution does not change the string
> >>in Version.java unless Version.java has changed. To solve the annoyance
> >>of editing files, perhaps the revision could be made derived during the
> >>build process. The OpenTTD folks write a "#include" file for their C++
> >>code at build time with the revision and uses that verbatim "in-game".
> >>They use the following to derive the revision:
> >>
> >>$(shell if test -d .svn; then svnversion . | awk '{ print "r"$$0 }'; fi)
> >>
> >>this has the benefit of working even with local modification (indicated
> >>by a "M" suffix).
> >>
> >
> >I don't get your point : why is it a problem that "local" changes aren't
> >displayed ? Don't you know what you are running ? ;)
> >
> >it's eclipse's fault ! last time I did shell scripting to update the
> >Version file, people complained : "it's not portable, doesn't work with
> >eclipse's auto-build" ...
> >
> >what's your proposal ? the shell thingy ? won't work on windows :)
> >
> Bottom line: the SVN revision number displayed by a running node does
> not match the SVN revision number of the code used to build the running
> node (assume no local changes for simplicity).
>
> This seems to be caused by Version.java's keyword substitution not
> reflecting the most recent SVN revision number but rather the SVN
> revision number of the last change to Version.java.
>
> I thought of the shell problem on Windows after I sent the message,
> though it's apparently a handled problem for the OpenTTD folks (they're
> not using Eclipse). Perhaps there's a way to pass it as an argument to
> Eclipse's auto-build?
>
> I don't know what FreenetLogBot's reported builds are being built with,
> but it it's the ant tool in a POSIX/unix environment, I think using the
> shell snippet above would be an improvement. Those who don't have that
> capability may be more familiar with their tools than we are and solve
> the problem with their toolset (such as I suspect the OpenTTD folks have
> done for their non-Cygwin build environments (though C, not C++ as I
> first remembered)). The shell snippet grabs the revision number, so if
> that's available elsewhere, it's not needed. In OpenTTD's case, the
> result is used to create a rec.c file from the Makefile. The rev.c file
> contains a few strings that are declared extern by all the other files
> that care. The Java analog may be more involved; I don't know Java well
> enough to suggest something directly other than a Revision.java file
> being fully created by the build process and containing a full class, etc.
>
> I just think the current situation either needs to be improved or it's
> not going to be able to achieve it's goal as I understood it to be
> intended when it was discussed on IRC over the weekend, IIRC.
>
Fixed/done : should work now.
NextGen$
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20060511/34dbfbe8/attachment.pgp>
