Keiron, See below.
Keiron Liddle wrote: >Hi Peter, > >On Thu, 2002-05-23 at 12:51, Peter B. West wrote: > > >>The full range of what I want to do with versioning I am not sure of; >>the minimum I am sure of. I canvassed this a short time ago. That is, >>to eliminate the situation where the identification of a build depends >>on manual intervention in the build.xml file which may or may not match >>a tag in the CVS tree, which may or may not correspond to the full set >>of files in the release. I am astonished that this situation is >>tolerated, although I should not be astonished to be told that it is the >>general condition of Ant-based builds. >> >> > >Considering that *every* project has a version you would think there is >a standard and robust way of handling this. > My question mark is over the "robust". >>The first thing is to get the version information returned by the >>Version class to match a tag. That's easy. Include $Name$ and $Header$ >>in Version.java as, say, private static final String fields, and include >>getTag() and getHeader() methods which simply return those values. >> Modify getVersion() to manipulate the $Name$ tag value, expressed >>according to the convention which I have also canvassed, without >>response, here earlier. If there is no $Name$ value, a default version >>string, something like "FOP.Development" (a string which could not be >>generated from a legitimate tag) would be returned. >> >> > >One situation that might need considering is when there is no cvs. For >example the source distribution. They may also want to set the version >number themselves. > > Of course. All bets are off when the version control situation changes. But that possibility should not inhibit us, who are working from the CVS. >>That, obviously, is fairly easy to do. Trickier problems include: >> >>Reporting the new getVersion() string during the build. Done fairly >>easily by an Ant task which simply emits the derived string to the >>normal verbiosity stream. Should probably involve similar labelling >>procedures in Version.java and build.xml. >> >>Validating that the whole source tree corresponds to the tag in >>Version.java. This necessarily involves the inclusion of keywords in >>every source file of the build. Now there's a novel idea. Another task >>required, and it would be useful if I could get the canonical tag value >>back into the build somehow, as for example with backquotes in a >>shell-based unix build process. I don't know how to do this in Ant. >> >>I want to look at all of these things, but clearly not all before 0.20.4. >> >>Let me say a few words about the CVS tree. It's not a sacred site. It >>has branches in order, among other things, to enable isolated >>development. IMHO, all individual development should take place on >>personal branches, unless multiple developers are closely co-ordinating >>attacks on particular pieces of code. Make changes, find out what >>others are up to, merge into your own branch from the trunk as >>necessary, and when you're ready, notify everyone that you want to merge >>back to the trunk. Do that. Find, and resolve with the other >>developers any merge conflicts. Abandon the branch. Throw another one >>and move on. This tool allows such things to happen and protects >>everybody's investment, so let's take advantage of it. If a branch is >>abandoned without ever being integrated into a release, so what? >> >> > >That is true. >On the other hand this sort of approach does not enforce and promote >community development. > I think that "enforcing" and "promoting" community development are inimical concepts. I agree entirely that it does not enforce community development. Whether it promotes community development depends on your definition of that concept. At the least, I would not accept that it militates *against* community development. > In practice branches are used for version and >maintenance+bugfix or major changes and development occurs in the one >place. For unproved concepts something like a scratchpad is used. > I accept that that is the current practice. However, AFAICT, there is no compelling reason not to vary this practice. > Also >this doesn't really scale with more developers. > I see your point here. As more developers are added, and as more merge/resolve cycles occur, the overheads of the merge/resolve cycle become much greater and more time-consuming. However, the single-branch model doesn't scale either. That scaling problem is the rationale for the sort of CVS usage model I am speculating about. It comes down to a balance of difficulties, and, I suppose, the type of changes that are being made; major hacks or minor fixes. >Part of the reason can be seen from the resources available to the trunk >code. Gump provides a compile and project compatibility check. People >can grab a nightly download to check and use the latest build >(admittedly broken right now). Other developers can see the changes >directly. > The trunk is still the destination. Changes are merged into the trunk at whatever interval is appropriate to the scale of a particular development. There is also this advantage: once the trunk is working, you can have a situation where WIP need not break it, and only sets of self-contained and complete changes find their way onto it. Developers will still see the commits on other branches on the fop-cvs list. >I don't think protecting people from problems will lead to the solution >of those problems. > I don't think that describes the situation. >I'm sorry for the all too brief comment, I will try better next time. > ;-) Peter --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
