Allen Bierbaum wrote: > Marcus Lindblom wrote: > >> Dirk Reiners wrote: >> >>> Hi Marcus, >>> >>> I added something similar using pysvn and adding some dummy files to the >>> libs. It's output by osgInit() at the Notice level, and for each lib. >>> >>> >> Sweet! Is it retrievable via some API call as well? I'd like to be able >> to print it to my log regardless of the opensg-loglevel. >> > > I don't think there is an API to get this information yet, but I agree > that would make it much more useful. Is there already an API to get the > version number of a library? If so we should probably put the retrieval > of the revision number right next to the API version interface. Some > projects even consider the revision number part of the API version > number, for examples: OpenSG "1.9.4 r345". I know OpenSG doesn't use > numeric version numbers so this may not make sense for us though. > > One comment on the revision number code. As far as I can tell, the > revision number does not tell us what code was used to compile the > library. It just says what revision was checked out. This may sound > like the same thing, but think about branches (both release and > development) and tags. Because the revision number is shared over the > entire repository, there is no way based only on revision number to know > if we are building from a branch, tag, or the trunk. > > For example, imagine that we have 2 development lines: > > /trunk <- 2.1 (development towards 2.2) > /branches/2.0 <- 2.0 release branch > > if we want to build a release from the 2.0.x branch, we would check out > the latest version of /branches/2.0 from the repository. Even if the > last commit was on the trunk or another area of the repository though, > that will be the revision that we use when building the 2.0.x release. > > It looks to me like there are two ways to solve this: > > 1. Combine the version number of the library (2.0.x) with the revision > number from the code. This almost gives us a fully unique value and > will work in all standard releases cases (branches for releases and trunk) > > 2. Make the path from the repository part of the versioning information > with the revision number. This would would for releases, but would also > work for development branches and tags. > The repository path should definitely be available. It's very useful to disambiguate releases etc.
As I showed earlier, we use all available info (version number, revision number, path, modified flag) in our releases. Cheers, /Marcus ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
