switching to mercurial ... Done !

EDIT

The switch to mercurial have been made, you can found the new repository here :

http://bitbucket.org/gantz/mogre

You will need to download and install mercurial or TortoiseHG if you want a GUI here :

Tortoise HG site

Mercurial site


If you need more info about mercurial, see this page on the ogre site :
http://www.ogre3d.org/developers/mercurial

Original post :

With the 1.7 version of mogre, the plan is to move to mercurial as our source control system to follow the decision of the ogre team. The objective is also to rework the directory layout of mogre.

The question is, what do we keep from svn ? here 3 options that i have think of:

1. Keep everything, along with the history, i'm not really a fan of this solution since it will complexify the reorganisation of the directory layout.[/*:m]
   
2. Keep each important tag (mogre 1.6, mogrenewt 1.54 for ex), along with the trunk but remove the history. keep the directory layout for the tags, rework it for the trunk. i see it as good compromise.[/*:m]
   
3. Start with a new directory layout containing the latest trunk, and nothing else. faster, but that mean we redirect people interested by old versions to the svn.[/*:m][/list:u]
   
   Also, here the layout i have in mind for the trunk :
   
   
   1. Codegen : Contain Autowrap and cpp2java, the goal is to have one version for wrapping mogre and it addons[/*:m]
      
   2. Addons : Contain each addons of mogre like the mogre design library, mogrenewt, hikari. we could also add subdirectory for each family of addons, like GUI, Physics wrapper, input, etc.[/*:m]
      
   3. Main : Contain mogre source code.[/*:m][/list:u]
      
      About the sdk, we are on svn for now. Should we move to Mercurial also for this ? On the same repository or with it's own ?
      
      So, what's your opinion ? i think it's a great opportunity we have to make the mogre repository easier to use (and to maintain ) so speak up your mind !

As long as the history is available on the old SVN for a while it shouldn't be a big deal to start fresh in Mercurial.

How big would the Mercurial download with full or partial history be?

I tried to pull the whole history using hgsubversion and it died in the middle with some obscure errors. So maybe full history isn't an option anyway? Does it work for you?

Ciao, Imi.
PS: http://bitbucket.org/imi/mogre2010 is only the latest snapshot as of yesterday (plus some patch-changesets). Edit: It's about 25MB uncompressed and 9MB download.

I tried to pull the whole history using hgsubversion and it died in the middle with some obscure errors. So maybe full history isn't an option anyway? Does it work for you?

same here, i was expecting that the mogre history wouldn't be too large, but it seem it's not the case :/ or perhaps we are missing something ?

http://bitbucket.org/imi/mogre2010 is only the latest snapshot as of yesterday (plus some patch-changesets). Edit: It's about 25MB uncompressed and 9MB download.

do you have made a fork of the ogre source ? or is it a regular clone pushed to your own repository ? I'd like to made the same thing against the 1.7 branch anyway, so i wonder what is the best option.

Anyway, i have setup a test repo , it's not usable for now (still need to update the wrap / build setup of mogre to take into account the paths changes), but i feel like starting over with a clean repo is the best thing to do

I didn't include ogre sources. Mercurial's extension "externals" could be used to refer an original ogre repository. Or you fork. This would have the advantage of be able to provide an already patched Ogre source repository.

Ciao, Imi.

So is the mercurial repository at http://bitbucket.org/gantz/mogre official now?

It looks very different from the latest subversion, (at least if revision 318 from https://mogre.svn.sourceforge.net/svnroot/mogre/trunk/ is the latest subversion). But it *would* explain why there are some "/../" in a some build files too much

Ciao, Imi.

Yeah, i have reorganize the directory path. it's a clean start, but for the moment, it's not usable, i still need to update path on build settings, fork ogre, then compile a new version to assure myself that everything is setup correctly

i hope to make it official by the end of the week or the start of the next one.

For the sake of reproducibility.. GantZ: when you finished reordering, can you check in the latest version into subversion, and then use this unmodified subversion revision to create the mercurial repository? That way there is a clean connection between the two and the history is not really "lost" (for people determine to track something).

As it seems now, there is a difference between "end of subversion" and "start of mercurial".

Ciao, Imi.
(Edit: And please put the revision number that the mercurial was created from somewhere in the checkin - just if someone accidently modify subversion afterwards)

the mercurial repo is related to the head revision of svn, and when the switch to mercurial will be made, i will just remove the right to commit for everyone, to avoid any changes.

There is no specific changes between the end of svn, and the start of mercurial, just directory and path changes. the content is the same. I can commit the same thing to svn then mercurial. i'm just afraid, given the amount of path changes, that svn could get crazy (as it happen when you remove / add / rename directory with existing content ) . well, i can create a tag for the actual version to avoid any problem in this case.

So you move the burden to keep track of the renames/moves to the user? . No, fun aside. I know what you mean. "Da big rename" changesets suck hard in subversion!

Maybe you can do the moving and renaming in mercurial? Does it do this stuff better? (This would be another step of turning me into a Mercurial-Zealot )

Ciao, Imi.

i have close the poll, i was unsure about doing a fresh start with mercurial, but since no one seem reluctant with this option, i think it's better to do it this way.

Following you suggestio, i have commit the last svn rev in the mogre hg repo, and make the change to the directory layout (so you have 2 revision, one that is the same as the rev 380 on svn and the second that contain all the directory change).

Does it do this stuff better?

Definitely . you haven't a .svn (here it would be .hg) like with subversion in every folder of your repo, so moving, adding, renaming folder / files is way easier

Next step, i have to check that everything compile correctly with the new layout, and we can move to mercurial as official repo.

Does it do this stuff better?
Definitely . you haven't a .svn (here it would be .hg) like with subversion in every folder of your repo, so moving, adding, renaming folder / files is way easier


Horay!... wait.. "not horay"

Well.. hm.. from looking at http://bitbucket.org/gantz/mogre/changeset/caa4787262de it seems that mercurial doesn't recognize the move as a move, and that it does the old CVS-style of remove/add instead. SVN was at least half-baked, in the way that a moved file was linked to the former place but the former file was still "normally" removed. This made it possible to know where a file came from but not where it was gone to.

Seems like Mercurial did a step backwards here . Well, I hope the other features outweigh this.

Ciao, Imi.

It should recognize a move, if you move the files with 'hg rename' (or 'hg addremove -s<percentage>' / 'Guess renames' afterwards).

hm.. for SVN you needed the "svn mv" too, but I thought that was precisely what Gantz saw as cool thing in mercurial.

C:\>hg help rename
hg rename [OPTION]... SOURCE... DEST

aliases: mv

rename files; equivalent of copy + remove

Mark dest as copies of sources; mark sources for deletion. If dest is a
directory, copies are put in that directory. If dest is a file, there can
only be one source.
...


Hm, so it seems they use the same idea as Subversion. I have to try out whether it also got the same inherent merge problems that result out of this: If one changes in a file that another "moves", the first change can not be applied correctly because the information is lost where the file was moved TO.

Ciao, Imi.

weird, i have used rename of tortoisehg, and it have just trigger the explorer rename. since i haven't found a way of moving files like in svn (holding right click and drag 'n drop the selected item then select svn move), i have assumed (by your input, wrongly) that hg behave in a different way than svn, so i have just move it without using specific command. (i admit i haven't check out the result of my commit) i need to read a little more about hg use

well, i have been able to commit a new version, i will redo once more the mercurial repo, then it should be ok.

Just tried it out with a toy example. Seems like "just renaming" will indeed remove and add them without any context information. Using "hg rename" seems to work nicely - the deleted file also keeps information about where it was moved to, so a change to the moved file in any other cloned repository (or branch) will be merged correctly. So it's indeed better than Subversion. . Horay!

Ciao, Imi.

After some search on the net, i've see that the version of tortoise hg i use got a bug, and don't behave like it should when use rename. i have update, and remade the mercurial repo. It should be ok, just checkout if it's ok for you.

EDIT
For the moment, the build process is not really easy to grasp, there is a lot of little fix to do on the configuration, so it's safe to wait for an updated, complete process

For the moment, the build process is not really easy to grasp, there is a lot of little fix to do on the configuration, so it's safe to wait for an updated, complete process

Figured that. . So switching to cheering-mode: GO, GANTZ, GOGOGO!

Some suggestions that spring up my mind:

1. Put the CLR-header and cpp files into the patch-file (that create the files already within the OgreMain folders). Disadvantage: if any of the files have to be changed regulary in Mogre-development, it's easier in "real" files than changing around in patch files.[/*:m]
   
2. Include a GNU patch.exe and a batch file that patches Ogre and prepare for everything (and copies stuff around if the previous point is not a good idea)[/*:m]
   
3. Add the following (via patch-file) into OgreMain/CMakeList.txt around line 663:
   
# Added by Mogre
include_directories("../../Mogre/include/auto")
link_directories("${OGRE_SOURCE_DIR}/../../lib")
list(APPEND HEADER_FILES
include/CLRObject.h
include/CLRConfig.h
include/CLRHandle.h
)
list(APPEND SOURCE_FILES
src/CLRHandle.cpp
src/CLRObject.cpp
)

   For an example, look at http://bitbucket.org/imi/ogre/src/tip/O ... eLists.txt. This way, the CLR files will be added to the solution already when executing CMake. Problem: They require precompiled headers. I think it's easier to just add the line #include "OgreStableHeaders.h" at first line into both CPP files. I haven't figured how to instruct CMake *not* to use pre-compiled headers for some specific files.[/*:m]
   
4. AutoWrap could contain a button to execute cpp2java and automatically call it before producing the generated sources if the necessary XML's are not present.[/*:m][/list:u]
   
   If you like them too, but you are a bit busy, I can try to help on any of the points and send you patch-files.. just name it
   
   Ciao, Imi.

Could be good additions to mogre. right now, i haven't much time, so i have added you as writer on the mercurial repository. you will be able to add some of your change directly this way.

About the patching, it would be better to make a fork of ogre, so we can provide an already patched ogre, that would save a lot of trouble in the build stage

finally, we could say that the hg repository is ready , see first post for more informations

Where are the Mogre samples now? (https://mogre.svn.sourceforge.net/svnro ... e/Samples/)

everything is in the sdk svn, the current repository is used only for source code of mogre and it addons :

http://code.google.com/p/mogresdk/

So these will remain SVN or are you going to create a mercurial repository for the samples (and all the other missing stuff) too?

For the moment, they remain in svn, we could plan on switch to mercurial, but it something that need to be decided with kwertz, who manage the sdk project.

There was still a discussion with pro and cons about merging the Mogre and SDK ressources.
One point was the big size of some SDK parts.
An other point was, that it could be more clear for developers when SDK and Mogre changes are note merged in one history.

More I don't remeber now. You can read it yourself.
Here is the discussion start:
viewtopic.php?p=67373#p67373

The current Mogre repositories for the Mogre wrapper and most of the Mogre addons can be found here now:
Mogre at Bitbucket

The Mogre wrapper code is in this repository:
http://bitbucket.org/mogre/mogre

The Mogre addons are in this repository:
http://bitbucket.org/mogre/mogreaddons

The released files for Mogre can usually still be found at:
http://sourceforge.net/projects/mogre/

Was there any perticular reason why the old SVN repository wasn't converted to a Merucial repository (except for the poll)?

For those that are interessted, I've converted the MOGRE SVN repository into a HG repository and uploaded it to bitbucket. You can find it here:

https://bitbucket.org/manski/my-orig-mogre

If there was no perticular reason for discarding the history, now would be a good time to reintegrate it into the main HG repository as there are not many changes yet.

a good reason to do so is that with mercurial, you clone a repository instead of checking out the last version. that's mean you will download all the history with your local version. just comparing your repo with the actual one, the size difference is 60 Mo. Even on ogre, sinbad decided to ignore too old version, since the size of the repository would be too big otherwise. I don't think there is much people who are interested in getting all the history when they clone the mogre repository anyway.

a good reason to do so is that with mercurial, you clone a repository instead of checking out the last version. that's mean you will download all the history with your local version.

Sure, but I hope we don't always discard all the history when we feel that the repository is getting too big. Because we won't be able to avoid this "problem" when we're using a DVCS.

you clone a repository instead of checking out the last version. that's mean you will download all the history
Is there no way/parameter to ignore the history by downloading? (Or to ignore all history entries older than xxx days.)

Did we also dismiss the history in the add-ons repository?
(It's no criticism - I just want to know.)

Sure, but I hope we don't always discard all the history when we feel that the repository is getting too big. Because we won't be able to avoid this "problem" when we're using a DVCS.
I wouldn't be too concerned about that. the old repo was too big anyway, because it got generated source code at some points, and everything about mogre was stuffed in one place. now, with separate repository for mogre, it addons and the sdk, history size won't be an issue anymore.

Is there no way/parameter to ignore the history by downloading? (Or to ignore all history entries older than xxx days.)
well, since it's dvcs, you are potentially a "server", so you are forced to have the whole repository. i guess that if you just want the last version, you get a snapshot instead, but you lose everything about versionning then.

Did we also dismiss the history in the add-ons repository?
I haven't created this one, mstoyke could probably answer that. i suppose he imported addons from the main repository.

All the new repositories were created from scratch and the latest versions of Mogre and the addons were then imported. They do not contain any of the previous history. This was done to remove a lot of obsolete overhead, because of the mentioned overhead of DVCS repositories. There are no plans to start over again, so the history of these new repositories will not be lost or removed.

The subversion repository for older Mogre versions is always available for references. I doubt that anybody will ever look at them again, because most people will want to use the newer version of Ogre and so they will use the newer versions of Mogre. If anybody is still using old versions of Ogre/Mogre, please let me know. I'm very interested to hear about that, because I could be absolutely wrong in assuming that nobody uses these versions anymore

I doubt that anybody will ever look at them again, because most people will want to use the newer version of Ogre and so they will use the newer versions of Mogre.

People who want to compile MOGRE don't need the history; that's true. But then the history is not (primarily) for the end-users but for the MOGRE developers.

If anybody is still using old versions of Ogre/Mogre, please let me know. I'm very interested to hear about that, because I could be absolutely wrong in assuming that nobody uses these versions anymore

I just asked because I'm currently working on the C++/CLI wrapper and for some changes it's necessary/nice to be able to see who did a specific change (SVN blame/HG annotate). And for this I need the history.

Sure, I can use the old repository for this research. I just wanted to raise this question before we commit a lot of changes to the new repository and then realize that we'd like to have the old history as well in the repository.