Yes this is helpful. Now I understand much better what you were saying. I will definitively do that! Thanks you Yarko.
massimo On Apr 10, 10:15 am, Yarko Tymciurak <resultsinsoftw...@gmail.com> wrote: > On Apr 9, 11:28 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > I need to be educated. Here is my problem. > > Ok - this is rather simple... I can help... > > > > > I gave myself a rule of tagging releases as 1.XX.YY. The fact is that > > I commit before I build the binaries. It occasionally happens that I > > commit 1.XX.YY, build the binary and then I discover a problem (for > > example a file was missing because I forgot to hg add it). So I make > > the change and I commit again with the same tag. I can put the R in > > front as you suggest but this is not going to avoid this occasional > > problem. > > For the moment, let's forget the "R" --- and let's keep use of > terminology consistent. > Right now you are setting the VERSION file, and putting the VERSION > number in comments. > > Strictly speaking, you are not "TAG"ing the release, as you are not > using the mercurial TAG command, nor creating a mercurial TAG. A TAG > is something which will propogate to releaes - i.e. this tag will even > be in my local repository when I clone, and I can use with all the > mercurial commands. > > Your "labeling of version number" - as it is now - will not help with > _any_ of the mercurial commands: since it is not a TAG, mercurial > does not know about it. It is nothing more than checkin comment > "text" - the meaning you place on it is a human one, by convention - > it is not following the mercurial "convention" of using the TAG > command, so that mercurial commands to not know about it. BTW - > this discussion holds equally for ANY of the other version control > systems: that is, you should use the system's tagging commands to tag > releases in CVS, SVN, git, bazaar, ... > > > > > In the recent times I have automated the build process of binaries and > > these errors are going to be minimized if not disappear and release > > tags will be unique as you suggest. > > Since a mercurial TAG is nothing more than an alias - a way mercurial > associates a "name": a string of human choice - with a revision set, > you can update what the TAG is associated with in such cases. > > There may have been a time when TAGging in mercurial required a follow- > up checkin (I am not sure), but this is not true any longer. When you > tag, the TAGS file is udpated, and cached. > > You can see how this works with a simple test (I am assuming a bash > shell): > > $ mkdir repo1 > $ cd repo1 > $ echo "hello from repo1" > test.txt > $ hg init # create a mercurial repository here > $ hg st # show status: you should see one file unknown, "?" > $ hg add # add everything into version control > $ hg ci -m 'My first commit' > $ hg tag INITIAL #tag the current revision > $ hg status # you should see nothing modified or added; everything > is up to date > $ ls -la # see a .hg directory created by "hg init", and a .hgtags > file created by your initial "hg tag" > $ cat tag # you can see the changeset associated with your tag > $ # now, we'll clone this - just as if you were pulling from Google > code: > $ cd .. > $ hg clone repo1 repo2 # new repository created > $ cd repo2 > $ ls -la # see your .hgtags file? > $ echo "a second line" >> test.txt > $ hg status $ shows test.txt "M", modified > $ hg ci -m 'my change to test.txt' > $ cat .hgtags # show your current TAGs > $ hg tag INITIAL # can't do this accidentally - a good thing! > abort: tag 'INIT' already exists (use -f to force) > $ hg tag -f INITIAL # re-tag > $ cat .hgtag # all your previous tagged versoins are there > > The moral: Let mercurial keep track of the most current tag. > > If you now do "hg clone -r INITIAL repo2 mynewrepo" and get the last > revision tagged "INITIAL". > The tags can be used in any mercurial command that accepts a revision > (-r) option. > > For example: you can check what changed since the revision you have > your client's site on, and decide how / if to proceed in upgrading > your customer's application to the new web2py: > > $ hg diff -r R-1.75.1 -r R-1.75.2 > > You can see how other, significant projects use tags for release and > component tagging, for example: > > http://developer.symbian.org/wiki/index.php/Using_Mercurial_Tags > andhttp://developer.symbian.org/wiki/index.php/Developer_Guidelines:_Fou... > > I hope this has been helpful. > > Regards, > - Yarko > > > > > Massimo > > > On Apr 9, 7:52 pm, Yarko Tymciurak <resultsinsoftw...@gmail.com> > > wrote: > > > > On Apr 9, 7:31 pm, Richard <richar...@gmail.com> wrote: > > > > > alternatively you could check out specific versions from the mercurial > > > > repository:http://code.google.com/p/web2py/source/checkout > > > > I just browsed through the comments, pages of commits to find 3 > > > comments that say 1.76.4. > > > > I assume these are the release (and the latest one is it). > > > > If I have a client w/ 1.65.1, I have a lot of paging / date guessing > > > to go thru. > > > > That is why tagging release would be a good thing, and a service to > > > the community: I would be able to checkout by tag, and just get the > > > right thing. > > > If I wasn't sure of the right thing, I could check the hgtags file and > > > see what the significant checkins (i.e. the tagged ones) were. > > > > I am surprised this even elicits discussion, alternatives, rather than > > > simple agreement. > > > > - Yarko > > > > > On Apr 10, 4:25 am, Kenneth <kenneth.t.lundst...@gmail.com> wrote: > > > > > > Is there a place where I could download older versions of web2py? > > > > > Source version. > > > > > > I get still problems with the new version and can´t understand why. So > > > > > I thought that by trying to upgrade one version a time I could maybe > > > > > find out whats the problem. > > > > > > Kenneth -- To unsubscribe, reply using "remove me" as the subject.
