Which version of git to use ?

We've spent a bit of time putting up the git to push the svn updates into an "official" git mirror - but appears the version that is in the debian package is 1.4.something - whereas I have 1.5.something on my box. The difference between the two is quite dramatic - especially with the observed behaviour of the git-svn - when I used it, the end result was some stale files and directories in the git repository - which I do not observe on my git clone.

After a small bit of googling I've found this page on gnome project - which basically dooms the 1.4, even though the reasons are a bit more religious than I'd like them to be :-)

In short - it seems like the git users would need to always run the latest version of git in order for the thing to be usable.

Now, the cool thing is that of course, as usual, in the usual "let the million worlds bloom" motto, there's already a mercurial repository :-)

My conclusion for the git repo on opensim so far is: go for the latest git and install it from source (errgh. this is not too cool, but is there any other choice ?)

Opinions ?

opensim git mirror might soon get a new home

Appears my post on the dev list did find some fans of git - and Sean suggested we might have it on opensimulator.org.

Needless to say I'm quite excited about this. We did have a lot of discussions about dSCM a while ago, and Mercurial is another very viable alternative - I guess I got "stuck" to git because of the "first love" syndrome - and then mainly used the reviews to strengthen my highly biased point of view :)

I guess for the windows folks with the more pointy-clicky reflexes the git must be a pain in the neck. Although, I did find something which allows to run git on windows - since I am not really much of a windows guy, I do not have any practical experience beyond installing it and getting amazed that I get the whole unixy environment in just around 20 megs of download.

If you have any experience with dSCM usage in the crossplatform environment, that'd be interesting to know...

my current stance is that we should have probably both:
CVS->git, CVS->hg; and then the contributions can be easily pulled back into CVS, and picked up by the respective SCM's merges. (hopefully :)

Again, any practical experience in this area would be very interesting to know about - as mine is limited to merging my own small hacks - which are by definition quite small.

Opensim: attachments & (unofficial!) git repo

Yesterday I've committed my initial prototype code for attachments, after some hesitation and the discussion with the other folks - even though it is quite ugly, the ugliness was considered low enough for it to be pushed to the trunk.

So - enjoy attachments. Just keep in mind that it barely-works now :) The best you can do is put the cube on the head and run around. (Note, that to take it off, you will have to logout - I did not implement the "Detach" yet). Also - you can only wear the objects from world, not from inventory.

Another new thing I've done is the totally unofficial git repo for the opensim - mainly for my own convenience, but if anyone is interested to use it - feel free.

There are two repositories:

• http://opensim.be/git/opensim-svn.git/ - the "pristine" mirror of the SVN official trunk. Immutable.
  
• http://opensim.be/git/opensim-dt.git/ - "DT-tweaks-in-progress" - the above (the 'master' branch still mirrors SVN), but also contains a few other branches of varying degree of uselessness
  

Of note in "DT tweaks in progress" repository is the "dht" branch - I'll be playing with opendht/bamboo-dht for the purposes of sim status publishing (and maybe push some more stuff into dht). Currently there's a regionmodule called "DhtBambooModule" which does just that - registers to bamboo dht - the couple of instances that I run on my servers.

Git as a local tool for "staged commits"

Very interesting. I am using the git locally to help with my own "mess management" (i.e. to allow me to backtrack to the last "known good state"), and was wondering about reasonable way to actually perform the commits to SVN from it.

So, here it goes: http://ropeonfire.blogspot.com/2007/10/using-git-svn-with-mono.html

The open question though is, whether it is really a good idea to squash a few small commits for the subtasks into a single large one... From the understanding perspective of each individual commit - no, it's better to have smaller commits. From the perspective of having less "noise" in the log, it would be nice to have bigger chunks though. (Assuming they do not overlap).

Hmm... maybe it is a convention thing... Just create a unique prefix for each "task", and start the commit logs with it. Then it will be possible to view the smaller commits logically grouped together.

Git on windows

I must say that I start to like git more and more - it was very handy with the IDTP coding.

Now, there is opinion that it is unfriendly for windows users... Well.. I think I found a nice fork off it, which does not require cygwin..

http://code.google.com/p/msysgit/ - indeed no warranties, and all... :)

A few interesting comparisons of Mercurial and git

Being a curious and lazy beast at the same time as I am, I was wondering what the world has to say about another distributed SCM - Mercurial (hg). And as the traits are best seen in contrast, I was looking for the "Mercurial vs git" info.

Well, the harvesting did bring some interesting results.
http://www.jukie.net/~bart/blog/git-vs-hg shows an interesting comparison alongside with a few more links, which I won't reproduce here - go and read for yourself.

From what it seems, neither is terribly superior to the other, probably more a matter of personal preference.

I very much like the fine-grained modularity of git - it goes very well with my own philosophy that instead of having a single entity that attempts to do everything, one is much better off with a lot of small tools, each doing only one thing, and doing it well.

But since so far I've used it just as a local version management control tool, hard to say.. Well, I guess the time will show.

Git impressions, part 1

To give some news on git (as I said, I started playing with it):

I've pulled in the opensim repository with the changes via git-svn (the whole business is around 200mb - not sure if the SVN storage is much better), branched off the release where my previous experimental code was, put the diff there, and rebased that branch off the latest version (200+ commits ahead). RL things do take their time, so the resolution of the merge conflicts (around 5-6 places) was merely into successful compile - rather than something working. But the whole process was very quick.

Given that the "commits" into the git go locally - IMHO this makes it very viable at the very least as a local "helper" platform for better flexibility, complementary to SVN. One can do many tasks at once in separate branches - switching between them is a breeze.

As a wholesale deal - I've also installed some beast called "qgit" - the gui to browse/search commits (separate package). allows to browse the changes fairly quickly.

I am quite pleased so far - although this is indeed quite basic usage, will need to see bit more how it works out.

The rebase today (reapplying the changes I made yesterday, onto the today's fresh checkout) went without any need for manual intervention, with a single command:

$ git-checkout teleport
Switched to branch "teleport"
$ git-svn rebase
M OpenSim/Region/ClientStack/ClientView.API.cs
M OpenSim/Region/ClientStack/ClientView.ProcessPackets.cs
M OpenSim/Region/Environment/Scenes/Scene.PacketHandlers.cs
r2304 = 23102815f47624d6f0cba0274302e11e010d9245 (git-svn)
M bin/OpenSimAssetSet.xml
r2305 = 1739baaedcd750ff768014289470f89769d625d7 (git-svn)
M bin/OpenSimAssetSet.xml
r2306 = 19566b7e39ec001b572e1bb730b5a9878e486b48 (git-svn)
M OpenSim/Region/Physics/OdePlugin/OdePlugin.cs
M OpenSim/Region/Physics/Manager/PhysicsActor.cs
M OpenSim/Region/Environment/Scenes/SceneObjectPart.cs
M OpenSim/Region/Environment/Scenes/ScenePresence.cs
r2307 = 1cf771ea6af379fd6ea461f91c640551313298fc (git-svn)
M OpenSim/Region/Physics/OdePlugin/OdePlugin.cs
r2308 = 78ea566a282cd58a91a29d0d1f24db2a282dc70e (git-svn)
M OpenSim/Region/ClientStack/ClientView.PacketQueue.cs
r2309 = a693db9165ca881b94e971df25754c3eda6ab557 (git-svn)
M OpenSim/Framework/Communications/LoginService.cs
r2310 = d05e6d59e7fe4562f18f227caf72ae7b200de0ae (git-svn)
M OpenSim/Framework/Communications/LoginService.cs
r2311 = fe0cbbc15634d38380c25314990d23ccab26dc3c (git-svn)
M OpenSim/Region/ClientStack/ClientView.cs
r2312 = 8796cd87cd32b4c38ee34db5cd2674f3c25457cc (git-svn)
M OpenSim/Region/ClientStack/ClientView.cs
r2313 = 6cbec5269c486c0f502c55e665a62dd93f78bc33 (git-svn)
M OpenSim/Region/ClientStack/ClientView.cs
r2314 = 6ed08cd9f685740920ccb3f252571dd19ed71db5 (git-svn)
M OpenSim/Region/ClientStack/ClientView.cs
r2315 = 6ffbf70e55f31ae30e834ed947c27b9012f8af0c (git-svn)
M OpenSim/Region/ClientStack/ClientView.cs
r2316 = 87155e023edd3d9ae6482bd4cbf1c1a606b6a824 (git-svn)
First, rewinding head to replay your work on top of it...
HEAD is now at 87155e0... * Protip: Commit AFTER compiling.

Applying Some teleport code

Adds trailing whitespace.
.dotest/patch:25: public IInterDomainCommunications InterDomain
Adds trailing whitespace.
.dotest/patch:71:*
Adds trailing whitespace.
.dotest/patch:136: *
Adds trailing whitespace.
.dotest/patch:173: public bool InformOfArrival(string magicCookie, ulong regionHandle, AgentCircuitData agentData, LLVector3 position, bool isFlying)
Adds trailing whitespace.
.dotest/patch:175: if (OnArrival != null)
warning: squelched 7 whitespace errors
warning: 12 lines add whitespace errors.
Wrote tree 515a3b62544b5313f4693e3b00a4b778f3a36714
Committed: cfcc3fc5b25dc25f18caa1c9295c7eceac77c44b

Applying Fix the failed build (restructured namespace)

Wrote tree 3768941bd8fd7d2d1e8f0a240f3cc34433b59348
Committed: bb5771d7e1ec4901e737bab48d3cbe8a0eb79e49
$

(this little log also highlights some git cleverness about the whitespace changes - which is very good thing to have).

Trying out git...

Thanks to Sean Dague for mentioning git on the opensim-dev maillist.

It's been long time I wanted to try it out, but watching Torvalds' video gave it a new kick.

Apparently it is somewhat similar conceptually to some self-written hack I've been using for a while now. So, the hack will now be buried - the funerals will be quick and modest.

I'll write more once I have more impressions.