CEGUI (Crazy Eddie's GUI) Forums

Hi there,

it would be a great benefit to have git access to the CEGUI sources, too.

If I understand it correctly, sourceforge has the option to grant public read-only git access with just a mouseclick (http://sourceforge.net/apps/trac/sourceforge/wiki/Git), without touching your svn repository.

Cheers
- Mark

Though I would then have to move to git, which I have no immediate desire to do. Or in other words, as I understand it, while the initial migration to git is painless, I could not continue to use SVN and have the git repo automatically shadow the SVN one (or maybe I have understood it wrong).

I think I'll wait and see if anyone else decides to 'vote' for this change in this topic, and then decide whether it's something that would benefit the project.

CE.

I wasn't aware that you'd lose SVN access. In this case a change to git will be very unlikely - until you start using git by yourself, probably in another project.
You'd love it, I promise

Well, we'd not lose SVN access, rather we'd then have two separate repositories

As I say, I have no immediate desire to do this, though I'm not 'opposed' as such, I just struggle to see where I would gain anything by using git over SVN.

CE.

In my experience DCVS's like Git or Mercurial are in pretty much all ways superior to centralized systems like SVN. Basically, a DCVS can do everything a centralized system can, and much more. They might however be a little harder to grasp at first, especially if one's used to working with centralized systems.
In addition to the way it improves your personal workflow (with local branches etc.), things like GitHub also drastically improves the way other people can contribute to the code. The barrier of entry for someone to contribute to something hosted on GitHub is orders of magnitude lower compared to the current patch system in place for CEGUI (altough a good system in itself).
However, I understand that the benefits might not be apparent, and switching source control system isn't something one does lightly. My recommendation, if you're interested in looking at DCVS's, is therefore that you try out Git yourself locally using the git-svn bridge.
The git-svn bridge allows you to use git locally against a svn repository. This allows you to use pretty much all of the git features on your local tree, with the restriction that when you push your changes you do that against the Subversion repo. This is a technique I've used at work (where the selection of source control system already had been put in stone), and it works splendidly. It doesn't take long until one has adapted the workflow to using multiple branches, one for each feature, and doing much more fine grained commits.

To set that up you would execute this command:

That might take a while though as it will try to create all tags and branches. If you only want trunk you can do:

There's more info here.

If you decide to move, this bridge could be used to make sure that there's always a read only svn mirror available (to which some server automatically pushes all trunk commits). However, since Git and Mercurial use is so prevalent today I don't think there would be any need. Given today's tools it's probably not much harder for a developer to use git than svn.

DCVS's like Git or Mercurial

I do not want people to be confused by the terminology you use here. I understand what you mean, and they are related. However, I think we should clarify this. The first thing to note is that "DCVS" is literally a distributed version of cvs, see: DCVS. Mercurial and Git are generally referred to as DVCS's or Distributed Version (revision) Control System. It is important to clarify such things to avoid confusion.

In my experience [DVCS]'s like Git or Mercurial are in pretty much all ways superior to centralized systems

Did you ever consider that your experience may not be applicable? In my experience, a centralized system is pretty much all ways superior to decentralized systems. I am dead serious. But both of these are sweeping generalizations. My point is that these opinions are meaningless; opinions are worth less than nothing in a debate.

The most important topics in a debate are simply this: why and how. In order to understand the why, you have to understand the requirements. And in order to understand the how, you have to understand the options. But you presented neither the why or the how. If you want to convince someone (who is of at least moderate intelligence) of something, then you need to to present your points objectively.

So, instead of assuming what CEGUI's version control needs are, we should start by asking CE to explain them. We can present some fundamental needs, but we still need him to confirm and prioritize them: ease of use, ease of contribution, efficiency (bandwidth/speed), full-history or no-history checkouts or both, collaborative offline development, etc. and to then compare the features of each VCS to this list of needs. Hearing users needs is obviously important, but the majority of users do not post on these forums and their needs cannot be 100% assumed. Most users post when they have an issue, not when they are happy with a product.

I think that this discussion is good (I don't particularly 'like' svn myself), but so far the discussion has no objectivity. I would like to hear what CE considers necessary for CEGUI and how he would prioritize them. Not that CE is automatically right, but he obviously has a much better grasp on these needs than anyone else here does.

The git-svn bridge allows you to use git locally against a svn repository.

We should also consider the availability of cross-VCS integration / workflows. As you pointed out yourself, a lot of the distributive needs (local commits / branches) can already be achieved by using distributive models locally, so how does this affect the relevance of the central repository needing to be a distributive model? You say that contributions would be easier with something like git-hub, but you do not explain why or how it would be easier?

Also, I think Bazaar is worth considering in this discussion. I know people are more familiar with Mercurial, and that people like to jump on the Linus train, but the merits of popularity and/or celebrity endorsement only pertain to evaluation, not function. Bazaar is (now) just as quick as Mercurial and arguably easier to use. As for git, as far as I am aware it is still clumsy on Windows (which, based on download statistics and experience, a large number of CEGUI users develop on). Bazaar is distributive, but the workflow is probably closer to SVN than Mercurial or Git. Bazaar also has a hub: launchpad, comparable to hg and git hubs. Bazaar also makes it very easy to switch your local workflows between a distributive (hg/git-like) or centralized (svn/cvs-like) model. As far as I am aware, this is clumsy at best in both M or G.

But of course we cannot really give a fair comparison without knowing and prioritizing the needs (or desires) for CEGUI's version control.

I use SVN for most projects and I think it's a fine and powerful solution. I don't see GIT/Mercurial having any major advantages over SVN for CEGUI.

With Git/Mercurial, users would update from the CE's hub anyways so it's the same as SVN as far as that. I haven't used Bazaar at all, it's screenshots look promising, I might look into that just out of curiosity .

The absolutely necessary features are:
1) good, reliable and easy to use tools for Linux, Windows and MacOSX
2) sourceforge has to support it

To be honest I don't really care about the VCS. I am completely fine creating patches with my working copy. But SVN is IMO the best of the centralised solutions and Mercurial is IMO the best from decentralised (at least last time I gave them all a spin I had that opinion ).

I did not yet work with hg or bazaar, but I had to learn git in my current project. While the switch was pretty complicated in the first two or three weeks, I learned to love the system of git. As far as I understand, hg / bazaar follow a similar concept.
Probably I should mention something of my current project. We are currently about 50 developers, some of them being "integrators" for different components, and one that integrates the whole product.

We often develop different features at a time and "merge" the stuff afterwards.
One (pretty much simplified) example:
One group needs to port the software to 64bit, another group needs to switch from IPv4 to IPv6. In the meantime, the "normal" development (bugfixing etc) continues.

So team A (64bit) has the following view:
master --> 64bit-branch (lots of commits in there)
while team B has
master --> ipv6-branch (also lots of commits in there)
Then again, you have lots of users that provide patches for bugs:
master --> bug-xxx-branch

Note, that the "master" branches from above must not necessarily be identical for the three groups, but I think you'll get the point.

The larger works (e.g. ipv6) is divided into different sub-topics, e.g.
- add IPv6 support to general network communication
- implement IPv6 support to SNMP
- add IPv6 support to whatever kind of communication (e.g. SIP in my example)
Those sub-topics are generally left to a single developer or a pretty small team of two or three people at maximum.

Every user has his own local repository (where he can create branches as he wants to)
Every team has a shared repository (commonly the repo of the team leader), where he will put the sources he wants to share with the team members
Team leaders need to integrate the sources of the people into one single branch (e.g. by rebasing or merging, depending on the situation)
If the work is done, the new "master-ipv6" (or whatever branch) is then sent to the integrator, who makes the final decision, whether this is going into the release.

The IPv6 example already shows the major difference. I cannot think of an (easy) solution to give away subprojects to multiple developers. You can achieve similar results by creating patches for every commit and then hope, that the integrator (or the team members) can apply the patches in their repository.
You also could create a IPv6-WIP branch on SVN, but this is still harder to maintain, as commits will end up pretty much mixed, and every developer has to rebase his stuff every time a new commit is done.

From my point of view, it's already getting complicated, when you try to share sources between three different people working on the same subject. As everyone creates his own commits, the commit order will in most cases be somewhat different.

Another example is the latest development for animations, that (imho) would be pretty much easier with a decentralized vcs. The current way (distribute patches via the forum) isn't the best way to share sources. You always need to download a file and apply it to your downloaded sources. If you're working on something else in the meantime, it's pretty hard to separate "your" changes from "their" changes. With git, this is done with just a single command.
You create two development branches (your working branch and the animation branch), and probably create a third "latest" branch, with as well your development topic branch as the animation branch merged into. You also can always merge the latest fixes from the 7.2 development branch.
So you can use as well your modifications as the animation stuff in your own testing environment, but still have your modifications within a single branch, which you can roll out to CE. Found a bug in CEGUI? No problem, create a new branch, fix it and send it to CE - based on the latest 7.x development branch. Oops, this bug is already in 7.1? Found a bug in the animation source? Create a animation-fixbranch, put your changes there and send it to the animations developer - based on HIS latest work.
Yeah, you can also merge branches within SVN and you always could create as many branches as you want to, but it's a PITA (at least it was with cvs). Plus you have to do it on the (centralized) server and cannot create your personal development environment.

Another big thing is the speed. I took hours to clone the whole SVN repository to my private git server. It only took me a couple of minutes to transfer the git repository to my local machine and it takes less than a second to switch to another branch.

SVN is still great if you only have a couple of developers, but if you expect more and more people to help out with patches or new ideas, a decentralized versioning control system is the way to go.

If you want to stay with SVN, this is still fine for me - I always can work with my local git repository (see the git-svn comment above), and can create patches from my local branches. Working with SVN is perfect, if you just want to download the "latest and greatest" (which would be the 'master' branch in git), but accessing different features that are currently in progress AND working on something else in the meantime isn't very comfortable - expect I missed some hidden SVN features

SVN can do branches and merging too and would be useless without them, most of the differences are only in the way features are accessed.

MarkR wrote:SVN is still great if you only have a couple of developers, but if you expect more and more people to help out with patches or new ideas, a decentralized versioning control system is the way to go.

Exactly my point, CEGUI unfortunately only has 1 (one) developer in the team...

As said here, converting to git/mercurial is fine but I think it's a lot of work (migrating the repo, adjusting to the new tools, ...) for no gain at this moment.

There are some interesting arguments here, to be honest. And I'd like to thank all for posting them I might take a look at the situation again shortly, though I tend to avoid acts of reorganisation just to give the illusion of progress (Which means while I have other stuff to keep me busy, this kind of change will be a low priority).

CE.

Do not forget to check the process that Steve Streeting went through when evaluating the various DVCSs - Mercurial won by a small margin over Git, and Bazaar was ruled out due to it being slower than the rest.

I highly recommend Mercurial, especially since it's written in Python, and it features a very likeable syntax.

Here's a link to everything tagged 'mercurial' at Steves blog:
http://www.stevestreeting.com/tag/mercurial/

I don't think you can find a more thorough and unbiased review anywhere else.

jacmoe wrote:and Bazaar was ruled out due to it being slower than the rest.

SteveStreeting wrote:I’ve only just started experimenting with Bazaar, and so far I’m quite impressed...I dropped Bazaar from my evaluation due to lack of time and because it’s the least popular of the 3 in our community... If I pick Bazaar, I’ll be happy with both the core concepts and the GUIs, but being the least fashionable option almost no-one in the community will be happy that I picked it over the other two.

jacmoe wrote:I don't think you can find a more thorough and unbiased review anywhere else.

Unbiased? He is clearly biased towards "popular" DVCSs. By all means, we cannot expect him to face peer pressure! As I've said on these forums many times, popularity and celebrity endorsement can be good reasons to evaluate a product - but it is completely worthless as a measurement of quality. And regards to performance, as I mentioned above while a little slow in the past, is just as fast as Mercurial is now.

Please at least do some research before bashing a product because it is not the one you endorse; and check your sources dates. These kind of blind accusations only spread more ignorance

Jamarr: He was in the same position as CE would be if he had to choose a DVCS. Choosing something that's not widespread brings problems, even if the product was just mindblowingly awesome. More people would bitch about having to install a new tool (as Steve said) and there even could be people who just wouldn't contribute because of this.

TBH I don't see DVCSs worth it for CEGUI right now because there just aren't enough contributors (yet?). After all Steve did the switch because there is a lot of activity on Ogre code.

I disagree. A good product solve's problems, regardless how widespread it is or is not. I hate seeing people trying to advocate popularity as if it justifies the use of inferior products. If a product is better at achieving the customers needs than it's competitors, clients will migrate. A favorite quote of mine:

Friedrich Nietzsche wrote:Insanity in individuals is rare - but in groups, parties, nations, and epochs, it is the rule.

Regardless of that, I agree with you in that I cannot see any compelling reason to move to any new VCS. At least one has not yet been presented. My point was simply to counter the Git and Mercurial fanboyism

Jamarr wrote:Unbiased? He is clearly biased towards "popular" DVCSs. By all means, we cannot expect him to face peer pressure! As I've said on these forums many times, popularity and celebrity endorsement can be good reasons to evaluate a product - but it is completely worthless as a measurement of quality. And regards to performance, as I mentioned above while a little slow in the past, is just as fast as Mercurial is now.

Please at least do some research before bashing a product because it is not the one you endorse; and check your sources dates. These kind of blind accusations only spread more ignorance

You might be a MVP, but you can't read.
So don't be a moron - do some research before pointing your finger at people.

You could start here:
http://www.stevestreeting.com/2009/11/0 ... #more-2354

You will learn that he initially was leaning towards Git, but Mercurial 'won' in the end.
After a very thorough evaluation - (two months, maybe more?)

Bazaar fanboy, eh?

I don't bloody care.

I just brought this up because of the whole evaluation process - and thought it might be interesting to read the thoughts/pros/cons/whatever.

I bet you don't have the balls to accuse Steve Streeting of fanboyism - directly.
You disappoint me.

If CrazyEddie can learn something from Steves evaluation round, then I'm happy.

Git, Mercurial, SVN, who cares?

As long as it clicks.