Looks like you are starting to get the hang of it! I see 2 new commits: cumulative change for release 8.07-dev2 minor simplification
Notice how you first committed to your machine? With hg you can keep a history of commits on your own machine, independent of the main project on the server, and if you decide to publish them you can "push" them. This is handy for JBT because JBT is supposed to be a platform for people to tinker with. Now they have the ability to do revision control on their own hacked up copies of JBT, and they can synchronise that with the versions you publish, and perhaps give these changes back to you if relevant. That said, I must say, you have an interesting method of committing. General practice is usually to make a commit once you have a coherent change made that can sit on its own. For instance, a change to the web page, or a change to the optimizer dialog, or renaming an indicator. Once you have a collection of commits and you think it is time to make a release, you "tag" that revision with a version number, then make a zip file from the code at that tag (perhaps leaving out some files that you don't think should be in the zips?). If the user reports an issue, you ask which firmware, and then go back in the repository to that tag for that version, and look at the code as it was then.. etc... This makes it a lot easier for someone who has made their own local modifications and needs to synchronize with the repository. In theory they can step through each change set you committed, and because its more or less one small single change (which can span several files), they can track exactly what you did and make appropriate modifications to their code. If instead you commit everything all at once, it can be very overwhelming to try and figure out everything that has changed since the previous revision. I think this would become useful if someone finally gets around to working on a seperate version in parallel with the ability to handle multiple instruments. They can create their own branch running along side the "trunk" or "plain JBT" on their own machine, and every time you make a change, they can merge that change into their copy. The smaller the discrete changes, the more manageable it will be to implement and adapt them to the branch. On Jun 7, 7:49 pm, Eugene Kononov <[email protected]> wrote: > > Judson, I can't figure out how to commit. I checked out to the last > > revision, made changes, and committed, but the repository does not seem to > > reflect it. > > Oh, never mind, I figured it out. I never "pushed" after the "commit". There > is a first time for everything. Judson, see if I messed up anything. I'd > also suggest removing all tags and branches. These things tend to confuse > me. -- You received this message because you are subscribed to the Google Groups "JBookTrader" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jbooktrader?hl=en.
