FYI - I have used "INIT" and "INITIAL" interchangeably; they _should_ be the same string (I used the shorter "INIT" in what I really did on my computer, and sometimes forgot to change when I copied).
On Apr 10, 10:58 am, Yarko Tymciurak <resultsinsoftw...@gmail.com> wrote: > On Apr 10, 10:26 am, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > Yes this is helpful. Now I understand much better what you were > > saying. I will definitively do that! > > Thanks you Yarko. > > Glad you found this helpful. > > I'll also add / continue the example a little: > > If you want to UNDO a re-tag (let's say you change your mind about re- > tagging INITIAL in the previous example), > here's all you need to do (this applies to the global tags, which is > what I've been talking about): > > $ cat .hgtags > 27870cf55b98b5503d00da280ed15b7038d82764 INITIAL > 27870cf55b98b5503d00da280ed15b7038d82764 INITIAL > b715d4331a3c21e4b8507396b2c155da45d1468d INITIAL > $ # notice: there is the first tag, and a PAIR showing the re-tag > <from-to> > $ # edit .hgtags with your favorite editor, removing the re-tag > $ # that is, remove the last two lines, and save .hgtags > $ hg status > M .hgtags > $ hg ci -m 'undid retagging of INITIAL' > $ hg status # shows nothing - tags updated! > $ hg diff -r INIT -r tip > $ # 'hg diff' shows what has changed since the initial tag: INITIAL - > useful! > > Regards, > - 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.
