Mercurial is pretty sweet, but it is really different. The only
"serious" issue I have run into has to do with larger files (10m and
up).
I would not recommend it for large files (not that anyone really needs
to do this, although it is kind of fun in a Myth Busters kind of a
way...) If you choose to test the limits of Mercurial you can keep
committing large files and in addition to memory warnings when you
commit larger files when you eventually get up to the 75-100G range
(with a lot of larger files) things will begin to get very wonky
before finally exploding into an irreparable stream of error messages
and catastrophic repository failures as you move towards the 100G
mark, so you will want to make sure you have your testing fun on a
testing repo located on a testing system....
#### An excellent email on mercurial and web2py
This is a repost of my favorite mercurial email. It was done by Yarko
a while after Web2py itself was moved to Mercurial. I remember finding
it really helpful at the time because it packed in a lot of real world
mercurial usage that the web tutorials at to time where missing...
k - 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
On Feb 24, 1:43 pm, Ross Peoples <[email protected]> wrote:
> After reading Jonathan's posts about Mercurial, I have decided to start
> using it during my development. My only problem is I can't seem to figure
> out how to set this up properly. I am using MacHG and have only made a
> couple of test commits. Then, I wanted to download the web2py trunk and
> merge it with my web2py folder by using pull. I ended up with all of the
> commits for the entire web2py trunk. At first I thought this was cool, but
> then when I went to try and merge my last commit to the latest web2py
> revision, and I got an error about outstanding uncommited changes. I tried
> using update, but that gave me a different error.
>
> So my question is, how do I set up version control with web2py's trunk and
> my code so that I can merge my code with the latest web2py commits when I'm
> ready to update from the web2py trunk? In other words, I have no idea what
> I'm doing. I included a screen shot of MacHG to help explain things a bit
> better. Thanks.
>
> <https://lh3.googleusercontent.com/_we-JWtgkmps/TWamj4KhrsI/AAAAAAAAAA...>
