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.
