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
and
http://developer.symbian.org/wiki/index.php/Developer_Guidelines:_Foundation_Builds#Tagging_of_Package_and_Platform_builds
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.
