Unofficial T-Engine and ToME HG repositories

[elcugo]

I have finished conversion of some of the code in CVS to Mercurial and hosted it on bitbucket.org:

T-Engine: http://bitbucket.org/elcugo/t-engine/
ToME: http://bitbucket.org/elcugo/tome/

So go ahead and follow, fork, clone or otherwise peruse these repositories.

Mercurial can be downloaded from http://mercurial.selenic.com/

To clone the repository using the command line tool type in your terminal:
For the ToME module:
$ hg clone https://bitbucket.org/elcugo/tome/
For the Engine:
$ hg clone https://bitbucket.org/elcugo/t-engine/

(But it might be easier to use the 'fork' feature, or I can give you write access to that repo.)

If things go nicely, this may become the official repository sometime in the future.

[Nerdanel]

It looks like it's time to start googling for tutorials...

[AnonymousHero]

Just a minor issue:

The t-engine repo is missing a .hgignore file for "*.o" and the two "tolua" and "tome3" executables.

[AnonymousHero]

One more:

Is there a way to submit "merge bundle" requests to repositories on bitbucket.org? I have made a bundle which fixes a couple of minor cosmetic things in the ToME module, but I can't figure out how to submit it via bitbucket.

[elcugo]

There's a "pull request" button there? Is that what you need?

[AnonymousHero]

Yeah, tried clicking that. It just seems to serve to send a message to the repo owner(s). I doestn't seem to be possible to attach a bundle to the message, so I presume it's just meant for proper "forks" where you can supply a URL.

I suppose I'll have to find some "upload any file" service and give you the URL to that.

EDIT: Sorry about these beginnerish questions, but do you know of a good Hg GUI for viewing the current log and change sets? I'm specifically thinking of something I can run locally since I just have a local repo at this time.

[elcugo]

Mercurial installs hgk by default. It will let you browse the repository, and there is a list of GUI's in this page: http://mercurial.selenic.com/wiki/OtherTools

BTW I have applied your changes.

[Nerdanel]

By the way, how should I convert? I'm confused by how you can have copies and forks and suchlike.

[elcugo]

By the way, how should I convert? I'm confused by how you can have copies and forks and suchlike.

It's a lot like CVS except that you are eliminating the middle-man. Whenever you checkout (clone) a repository, you get a full copy, including all history. You can do all operations in your copy withouth needing a central server (here's the distributed part).

So you can revert, merge stuff, modify, without fear of altering anyone else's work. You can send your changes or get someone else's changes whenever you want.

Cloning a repository is a very fast and efficient task, it's for example a good practice to have 3 repositories, one synced to the official repository, one where you have all your changes and another where you can test someone else patches.

To checkout a repository, you use the clone command:
hg clone http://example.com/somerepo

You can clone locally, to have as many repositores as you need.
hg clone /path/to/repo /path/to/my/new/repo

To send your changes to another repository, you use the push command, it works for local and remote repositories.
hg push /path/to/repo

If you omit the path, it will default to the repo you cloned from.

To get changes from another repo, you use the pull command, it works similar to the push command and will also default to the repo you cloned from.
hg pull /path/to/changes/repo

However, if you pull, you need to execute the update command, that will actually modify your working directory:
hg update

When you have changed files in your copy, you must commit them. Mercurial will ask you for a commit message, just like CVS
hg commit [files]

But before you commit, make sure you run the status command to review the changes.
hg status [files]

And to see what actually changed, use the diff command:
hg diff [files]

If you omit the files parameter, the command will be applied to all files.

That's a quick introduction, there's much more that can be done, but I think I have covered the basics.

[Nerdanel]

So I switched to Mercurial and the things went smoothly. It's a bit intimidating to get accustomed to a new set of commands, but I think I'll manage.

In the name of actually achieving something I'd probably better put the randarts and the mystery bug on hold for now and start thinking of what can be done for the dungeon/wilderness combinations.

[Falconis]

Just cloned the t-engine and tome module from the hg repos.

Will have a look at them tonight.

(Yeah, it's been a while... Hi!).

[Falconis]

Hmm, well it compiles. (Using Visual Studio.)

Had to move cmonster_msg to the top of melee2.c and change the #define stricmp strcasecmp to #define strcasecmp stricmp, but nothing else, IIRC.

I'm getting crashes though... The debug version triggers a breakpoint with heap corruption somewhere in the SDL init code. The release version gets a bit further (I can select a module and it loads the ToME module, but then crash. If I can get the debug version a bit further I might see why...

[Falconis]

Ok, I've uploaded my changes on bitbucket (a few bug fixes, some tidying) and submitted a pull request. Hopefully I've not been too cavalier in jumping right in and changing stuff.

As far as bugs go, is it possible to use the bugs.t-o-m-e.net site still? (can things be marked as resolved?) If not I'll submit bugs to the bitbucket issue tracker (probably better than using the wiki). I'll take a look at the bugs lists around the place and see what I can reproduce (given the age of some of the reports, I guess that many may not be problems any more). I've noticed a whole host just from basic testing (mainly tome module, but a fair few t-engine things).

I'm happy to start fixing up the SDL build (the windowing system is horribly broken). Once it's basically functional, I guess it's on to the tome module...

Any guidance as to important things to fix would be appreciated. Cheers,

TF.

[elcugo]

Hello Falconis, I received your pull request, will check it out and pull it tonight!

I think bugs.t-o-m-e.net is still the best place to post bug reports, it's very underused right now and seems not anyone cares about it anymore, so it needs a lot of love. One problem is that few developers have access to close reports and stuff. Bug reports on bitbubket are ok too I guess, but if it's too confusing I guess I can disable it.

[Falconis]

Enh. Just realised I forgot to update the makefiles when I removed help.c (the last revision I uploaded), so you might not want that one.