SFML community forums

General => General discussions => Topic started by: Laurent on March 18, 2011, 01:19:53 pm

Title: My plans for the website tools
Post by: Laurent on March 18, 2011, 01:19:53 pm
Hi

In my process of upgrading/changing everything before SFML 2 is out, today I've decided which tools I'm going to use. Just let me know what you think about it ;)

* forum : SMF 2.0 RC5
* code repository : switching from SVN to GIT, and from sourceforge.net to github
* task tracker : the one provided by github
* wiki : the one provided by github

In case you're scared by so many changes:
- I can export the current forum to the new one without losing anything
- I can export the current SVN repository to the new one without losing anything
- I can export the current tasks to the new tracker manually, there's not much to do :D
- I will probably not be able to import the wiki however, so I think I'll need a little help for that

I keep it short, just ask questions if you want or leave your comments ;)
Title: My plans for the website tools
Post by: Nexus on March 18, 2011, 01:42:34 pm
Why do you switch from SVN to Git? I'm not too familiar with Git, but it seemed to me rather complicated compared to SVN (which I consider a very nice version control system). On Windows, TortoiseSVN is also a great tool, is there something similar for Git?

Isn't SVN also used more widely? I personally don't know a lot of people using Git.
Title: My plans for the website tools
Post by: panithadrum on March 18, 2011, 01:45:30 pm
Quote from: "Nexus"
Why do you switch from SVN to Git? I'm not too familiar with Git, but it seemed to me rather complicated compared to SVN (which I consider a very nice version control system). On Windows, TortoiseSVN is also a great tool, is there something similar for Git?

Isn't SVN also used more widely? I personally don't know a lot of people using Git.

I'm wondering the same as Nexus. Anyway, there is TortoiseGIT!
Title: My plans for the website tools
Post by: Groogy on March 18, 2011, 02:18:50 pm
Git is getting more and more actually. For instance the whole Ruby project is located on Github if memory serves me right.

Is there a TortoiseGit?

Anyway it will be much better to have everything located at the same place. I can help you with moving the english part of the wiki.
Title: My plans for the website tools
Post by: Laurent on March 18, 2011, 02:24:46 pm
Quote
Why do you switch from SVN to Git?

GIT is really much better, in fact after using it everyday at work I can hardly work with SVN anymore. It would be really long to tell you why it's better, I guess you can find such comparisons with Google; but if you don't I'll try to elaborate a little bit ;)
The most important thing is that it's a decentralized system, which means that there's no server, only clones. So people (especially me) can work locally without pushing anything to the main clone, or can fork and work on their own clone and then submit a "pull request" (which is a request to merge their clone to the main one), etc. Branching and tagging is also much more flexible and lightweight.

Quote
I'm not too familiar with Git, but it seemed to me rather complicated compared to SVN (which I consider a very nice version control system)

In fact GIT is a superset of SVN (you can even use GIT on top of a SVN repository directly). So at least you can do exactly the same as you did with SVN, and if you want more you can learn a little bit about the extra commands and do more powerful stuff.

Quote
On Windows, TortoiseSVN is also a great tool, is there something similar for Git?

Of course, every version control system has its Tortoise app ;)
Here it's TortoiseGIT, and it behaves exactly the same as TortoiseSVN -- maybe too much, sometimes it's confusing because it keeps SVN concepts unchanged but they don't match GIT anymore.

Quote
Isn't SVN also used more widely? I personally don't know a lot of people using Git.

In fact I think that GIT, and decentralized systems in general, are getting more used and will eventually replace SVN one day. Because decentralized systems are really more powerful.
Have a look at github and gitorious, you'll see plenty of well known projects using GIT.
Title: My plans for the website tools
Post by: devlin on March 18, 2011, 02:36:44 pm
I for one welcome the change to GIT. It's far better for managing code - but SVN still has its strengths (like large binary data like media files that aren't easily mergable - requiring locks on files to prevent people from doing work in vain).

You should celebrate the move to GIT by getting the ATI fix out on it ;)
Title: My plans for the website tools
Post by: Laurent on March 18, 2011, 02:43:56 pm
Quote
You should celebrate the move to GIT by getting the ATI fix out on it

I will 8)
That will be my first branch (by the way, sfml2 will become master and trunk will be a 1.6 tag), so that people can test it and give feedback before it's integrated "officially".
Title: My plans for the website tools
Post by: pdinklag on March 18, 2011, 03:16:06 pm
Git is probably the better choice for the distributed development of the several bindings.

You might reserve a repos for a Java binding, cause I might decide to make mine public, it's working pretty well so far. :)

Quote
You should celebrate the move to GIT by getting the ATI fix out on it

Yay!
Title: My plans for the website tools
Post by: Laurent on March 18, 2011, 03:24:59 pm
Quote
You might reserve a repos for a Java binding, cause I might decide to make mine public, it's working pretty well so far.

I still don't know what will be the best way to handle external bindings with GIT:
- keeping them like they are currently, on the main SFML repository?
- asking developers to create their own github repositories, and using sub-modules or forking?
- kicking them out and let them use whatever they want :D
Title: My plans for the website tools
Post by: Groogy on March 18, 2011, 03:52:54 pm
Well I think the most important thing is to keep a link from the website to have it easy for people to find and download them.
Title: My plans for the website tools
Post by: pdinklag on March 18, 2011, 03:59:26 pm
Dedicated repositories per binding would be the way to go if you ask me, but they should all be linked to the SFML project as Groogy mentioned. That can be done on the website. Have a separate "Bindings" page and mention them there.

That way each author can decide what he wants to use. If github allows multiple repositories per project, that would be a way, too.
Title: My plans for the website tools
Post by: Tank on March 18, 2011, 04:30:58 pm
Holy gosh! I really appreciate every single change you announced.

I've been using the SFML repository in a local Git clone for a very long time now to be not forced to use that SVN crap, again (like you said: once you get used to it, you will never want to get back to a centralized system like Subversion). And to everybody who hasn't worked with Git, yet: Pay attention when using tools like TortoiseGit. It tries to simplify things but sometimes hides the philosophy of Git. So you better start off by using the Git binary directly. Once you're used to it, you may switch-over to a GUI (but I bet you don't want to do that, then ;)).

SMF2 also sounds good. We have that version running for several weeks now at sfml-dev.de and are quite pleased with it. No problems so far.

For the project management stuff I think GitHub will be a good place (issue tracker and wiki). If you have Ruby-enabled (or Rails) webspace, you may want to take a look at Redmine (if I remember correctly, you're already using it for CAMP). But however, I think it's a great step forward for SFML because it's an easier way for contributers to jump in.

Regarding the bindings: Personally I go with pdinklag, however you have to clarify: If bindings are officially supported by SFML, then they may be included in SFML's upstream repository. However this can be confusing when, for example, the .NET binding is mainly maintained by you, so you include it, and others like Ruby are separate. So the best option would be to completely kick them off of SFML's repository IMHO.

Keep it going! :)
Title: My plans for the website tools
Post by: Laurent on March 18, 2011, 04:45:10 pm
Quote
If you have Ruby-enabled (or Rails) webspace, you may want to take a look at Redmine (if I remember correctly, you're already using it for CAMP).

That was my second option, but using github will:
- save SQL space on my own website
- save one additional authentication for users
- save installation/maintenance time for me

Quote
If bindings are officially supported by SFML, then they may be included in SFML's upstream repository. However this can be confusing when, for example, the .NET binding is mainly maintained by you, so you include it, and others like Ruby are separate. So the best option would be to completely kick them off of SFML's repository IMHO.

Yep, sounds good. However I hope that it won't become too complicated to retrieve and compile all those separate things, compared to the current situation where everything is at the same place.
Title: My plans for the website tools
Post by: Nexus on March 18, 2011, 05:23:50 pm
Quote from: "Laurent"
GIT is really much better, in fact after using it everyday at work I can hardly work with SVN anymore. It would be really long to tell you why it's better, I guess you can find such comparisons with Google; but if you don't I'll try to elaborate a little bit ;)
I think I will take the opportunity to learn Git when SFML starts to work with it. As I understand it, the switching is more or less definitive :)

Quote from: "Laurent"
Of course, every version control system has its Tortoise app ;)
Here it's TortoiseGIT, and it behaves exactly the same as TortoiseSVN -- maybe too much, sometimes it's confusing because it keeps SVN concepts unchanged but they don't match GIT anymore.
Hm, do you know a good alternative? I'm not a big fan of command line tools on Windows, however shell extensions like TortoiseSVN are quite convenient in my opinion. May I ask what Git tool you are using (given you even work with Windows)?
Title: My plans for the website tools
Post by: Tank on March 18, 2011, 05:47:12 pm
Quote
Yep, sounds good. However I hope that it won't become too complicated to retrieve and compile all those separate things, compared to the current situation where everything is at the same place.

True, but I think the proper maintainers will take care of that so that it's as easy as presently. They can still stick to the bindings/ sub-directory, i.e. the readme says "Extract the archive to your bindings sub-directory of SFML and blah...".

Quote from: "Nexus"
Hm, do you know a good alternative? I'm not a big fan of command line tools on Windows

TortoiseGit works without problems, you just have to make sure you understand the principles of Git, which may get a bit lost under the Tortoise GUI. In my opinion using the CLI of Git is the best way to learn it.
Title: My plans for the website tools
Post by: devlin on March 18, 2011, 06:48:04 pm
Quote from: "Laurent"
Yep, sounds good. However I hope that it won't become too complicated to retrieve and compile all those separate things, compared to the current situation where everything is at the same place.

You could issue a pull into the master on every major version (i.e. 2.0, 3.0 etc) or the maintainer of the binding could issue a push-request to master (which you then accept or not) when the binding is supposedly stable? Kinda like how Torvalds does it with Linux.

Any thoughts on user-made addons in all of this?
Title: My plans for the website tools
Post by: Laurent on March 18, 2011, 08:45:54 pm
Quote
May I ask what Git tool you are using (given you even work with Windows)?

Both TortoiseGIT and command line. TortoiseGIT is convenient when you have a strong Windows/TortoiseSVN background, but you soon realize that:
- things that require 20 clicks can be done in 2 or 3 commands maximum, without moving your hand all around the desktop to reach the buttons
- complicated actions are more error-prone with a GUI than with command line + vim
Title: My plans for the website tools
Post by: xazax on March 18, 2011, 10:11:45 pm
A bit off topic but can TortoiseSVN and TortoiseGIT be installed side by side without any issue?
Title: My plans for the website tools
Post by: Tank on March 18, 2011, 10:12:19 pm
Quote from: "Laurent"
- complicated actions are more error-prone with a GUI than with command line + vim

Which ones for example? Just wondering (not flaming ;)) what actions you could mean since I never felt like needing a GUI. Even the CLI has some interactive command versions that can be used.
Title: My plans for the website tools
Post by: Laurent on March 18, 2011, 10:36:03 pm
Quote
A bit off topic but can TortoiseSVN and TortoiseGIT be installed side by side without any issue?

Yes. I have them both at work and at home, and there's no conflict or problem between them.

Quote
Which ones for example? Just wondering (not flaming ) what actions you could mean since I never felt like needing a GUI. Even the CLI has some interactive command versions that can be used.

Interactive rebasing, and in general anything which is about editing/moving/merging commits.
Title: My plans for the website tools
Post by: Groogy on March 18, 2011, 11:43:23 pm
Just thinking for the bindings part.

So that would mean I place my own repo on github right? Talking all about these pull request and etc. etc. I only used Git just like how I use SVN. So seems like I've missed out much huh? Well when you've decided if you want the bindings in their own repo or in the SFML2 repo I'll bet I'll have a thousand questions ^^
Title: My plans for the website tools
Post by: Laurent on March 19, 2011, 10:03:37 am
Quote
Well when you've decided if you want the bindings in their own repo or in the SFML2 repo I'll bet I'll have a thousand questions ^^

I know :D
Don't worry, when something is decided I'll make as easy as possible for bindings maintainers.
Title: My plans for the website tools
Post by: Hiura on March 19, 2011, 02:31:48 pm
Sounds great!!  :)

I've been working with git during the last months and I love it!
Title: My plans for the website tools
Post by: coolhome on March 19, 2011, 07:43:17 pm
This is awesome! GIT is so much better then SVN. I used to like SMF but now I like MyBB (Free) and XenForo (Paid) for forum system. Oh well at least SMF is better then phpbb!  :D
Title: My plans for the website tools
Post by: Klaim on March 20, 2011, 11:28:44 pm
Hi!

Laurent, just to be sure : you could have choose Mercurial. Why did you choose Git in the end?

I suspect two main reasons, please correct and complete my assumptions:

1. You're now used to git : as you said you use git now so maybe you didn't need to use mercurial and just used what you use everyday.
2. GitHub is really nice and there is no real challenger yet for it, as the collaborative features are still not matched by BitBucket, Google Code, etc...

If there are other reasons I'd like to know. I've tried essentially Mercurial because it's so much easier to learn than git and have less compatibility problem than Git on Windows (because it relies a lot on a linux environnement).

I suspect this last point to not be up to date. But I'm not informed enough. So I'm interested in any informations about the decisions to choose one or the other (or Bazaar and other alternatives).
Title: My plans for the website tools
Post by: Laurent on March 21, 2011, 07:41:52 am
Honestly I'm not going to compare every single versionning system that exists. Git is a popular choice, it does exactly what I need, and I'm very comfortable with it.

Quote
I've tried essentially Mercurial because it's so much easier to learn than git and have less compatibility problem than Git on Windows (because it relies a lot on a linux environnement).

Git works on top of cygwin on Windows.

Quote
So I'm interested in any informations about the decisions to choose one or the other (or Bazaar and other alternatives).

Should be easier if people experienced with other systems tell me why I should consider choosing another one ;)
Title: My plans for the website tools
Post by: Klaim on March 21, 2011, 11:29:50 am
Ok no problem I understand your choice and it's good. :)

Quote
Git works on top of cygwin on Windows.


Yes. It's still unperfect because of this.

There is also a lot of errors occuring in git that don't give any feedback, but it seems to be fine as far as you don't do "ninja tricks".

About choosing mercurial instead of git, I did it because 1. it's easier to understand (but that's only a timing problem if you're going into git I guess) 2. it's done with python so it's easily extensible, cross-platform by nature etc.

In fact I followed the research made by the OGRE3D guy that are available on his blog (http://www.stevestreeting.com/2009/11/06/dvcs-score-card/) - he now sells a MacOS tool for managing repositories (git,mercurial,svn) (read the previous related articles too for details). I recommand the reading to understand the forces and weakness of each at the time. Note that for example Gitorious isn't now as interesting as GitHub, because of GitHub community developpement tools.

I personally think that GitHub is excellent, so I'd like to use git more but it require clearly more learning time than Mercurial that mostly do the same but without a GitHub. Google Code and BitBucket are currently enough for my open source projects so that's ok for now.

As I don't like to be dependant on one tool for the same problem, I try to learn the others when I have a project that might benefit from it, so I read a lot about those things, just to understand the alternatives, that's why I was asking.

It seems that the boost people will go to git again, so I might force myself to be familiar to both Mercurial and Git for all my projects.

What's too bad, as the Ogre guy said, is that it seems possible to make something as powerfull and cross-platform than a mix of Git and Mercurial and that would have a GitHub. But it doesn't exist XD.

Anyway, you could also find some other comparison about the two tools (and others like Bazaar (used by the ubuntu team) and Fossil (that is more for little projects, as they say themselves on the comparisont to git page) ) but I think for Mercurial and Git, the Steve's comparison might be the more pragmatic, even if you don't choose the same than him.
Title: My plans for the website tools
Post by: Laurent on March 21, 2011, 11:46:08 am
Thanks for this useful pieces of information, I'll read the blog article carefully :)
Title: My plans for the website tools
Post by: Tank on March 21, 2011, 05:29:45 pm
I don't get the point what's so "hard" about Git. Mostly you need exactly four commands, git-add, git-commit, git-push and git-pull. Sometimes git-rm, more often git-checkout or git-merge. All of them are well documented and easy to use (once you know how Git works!), most of them are even not worse looking them up in the docs. ;)
Title: My plans for the website tools
Post by: devlin on March 21, 2011, 06:07:16 pm
You don't even need that if you're using windows and a decent editor. There's stuff like GitExtensions that handles everything for you (MSVC).
Title: My plans for the website tools
Post by: Svenstaro on March 21, 2011, 11:43:57 pm
I, for one, welcome all the changes, especially git. The lack of remote tracking branches in Mercurial really puts me off and makes managing and reviewing other people's forks hard.
Title: My plans for the website tools
Post by: Arwel on March 22, 2011, 10:05:20 am
This is such a good news ! I can't wait to fork it !
Title: My plans for the website tools
Post by: Klaim on March 22, 2011, 11:04:37 am
The hard things with gits are, if I understand correctly :

 1. coherence of lexicon : the words used are not as intuitive as subversions and mercurial. That said, indeed once you learn it it's not a problem anymore.
 2. lack of feedback on errors : that can be a problem for "we don't have time for this shit" business - but that's ok for those who passed enough time studiying git to understand their errors easily
 3. complex manipulations are too complex : most of the problems with git arise when you use more than the 4 basic commands. Same thing with any control source software in fact. You have to understand that big projects have to manage their sources, branch, tags etc. in a really complex way that require understanding precisely how the source control software does work.
 4. Windows port has often been a problem (not sure it is still) because far from being stable. As most developers around the world still use Windows as main developpement plateform (and maybe target), that don't help. Use it on Mac & Linux and you're safe and feel power. Use it on Windows and you might have some troubles. Now, as said, I think there have been a lot of improvements and I don't know the current status, so I'm interested in feedbacks about that too.

So, when you want a DSVC, I think there are globally two cases :

 1. you're working with people that are familiar with git, so you choose git, or with mercurial so you choose it, etc.
 2. you and you team don't know much about DSVC. Then if you have time you learn git (because we hear a lot about it) but if not you'll use whatever works without a lot of thinking (like Mercurial). Whatever choice suits you, don't rely on other's voice without arguments.


There are differencies between git and mercurial that make them unperfect choice BOTH. Whatever you choose, understand that the cost of understanding git can be costly for some business. In the same way, some people say that for really massive sources, using git is really better than mercurial. I know there is some subtile structural differences between both but I don't understand yet what are the cost of each architectures.

Anyway, choosing git or mercurial or any other is good, as far as it's decentralized. It really helps "lockfree" parallel work ;)

And as both mercurial and git provide ways to work with each others, there is no problem. I'm using sub-repos on mercurial by the way, that's really excellent for big projects that need separation of some parts.

I wish GitHub would provide native Mercurial support... that would be the dream :)
Title: My plans for the website tools
Post by: Svenstaro on March 22, 2011, 12:29:34 pm
Laurent, since you are already changing and reworking the web stuff, how about optional https support?
Title: My plans for the website tools
Post by: Tank on March 22, 2011, 01:05:19 pm
Quote from: "Klaim"
1. coherence of lexicon : the words used are not as intuitive as subversions and mercurial.

That's because you're used to them, and Subversion and Mercurial share a huge part of terminology. In Git there can't be a "git update", because you don't have a centralized server to update from. "update" means to fetch new commits, but since you always HAVE the repository on your harddrive, there's nothing to "update". Same goes with "git commit", where many people are confused because it doesn't "commit to the 'main' repository": It does what it says, commit your staged changes to YOUR repository. As soon as you've learned the fact, that you own a fully working and complete clone of the repository, things will get easier immediately.

 
Quote
2. lack of feedback on errors : that can be a problem for "we don't have time for this shit" business - but that's ok for those who passed enough time studiying git to understand their errors easily

 That counts for every software, not only SCM. If there's an error you don't understand directly, you have to look it up. Happened many times before with me and Subversion due to strange behaviour (lockups, cleanups, the list is long).

 
Quote
3. complex manipulations are too complex : most of the problems with git arise when you use more than the 4 basic commands.

 I understand what you mean, but I think things get easier once you dive deeper. I love to compare this with Vim: When you start, you don't have to know the full commandset, only the basics to get you started. As times passes by, you may have the feeling of "Can't this be done more effectively?", then you fire up the docs and check if there's anything you can do better.
 
 Same goes with Git: You will probably do a lot of "revert stuff" manually in the beginning, or wild copying between your working copies. Later you get used to cherry-picking, rebasing, commit rework etc.

 
Quote
4. Windows port has often been a problem (not sure it is still) because far from being stable.

 I can't tell you MUCH about this, however the times I've used Git on Windows it worked perfectly and didn't have any noticable problems (I used the CLI version aswell as TortoiseGit). But since I'm mainly on Linux, there're probably others who know this better.

Quote
1. you're working with people that are familiar with git, so you choose git, or with mercurial so you choose it, etc.

You forget the part that says "The team has used SCM A, but after testing out B, they switched to SCM B." ;)

Quote
There are differencies between git and mercurial that make them unperfect choice BOTH.

That's true, absolutely. Most SCM have their raison d'ĂȘtre. I wouldn't use Git on data that's huge and binary (like drawings), for example. But when talking about DSCM like Git, Mercurial and Bazaar, then my choice is made. ;)

Quote
Whatever you choose, understand that the cost of understanding git can be costly for some business.

Using something different or new always means that it costs time and breaks the "normal work" of a "business". The question is: Is that time well spent? For example, you only need 2 weeks to master Subversion, but 6 weeks to master Git. But if you're so much more productive with the latter, why shouldn't you invest the time? (replace Subversion and/or Git with anything, just an example)

Quote
Anyway, choosing git or mercurial or any other is good, as far as it's decentralized. It really helps "lockfree" parallel work ;)

Definitely, yep. I want the power of an SCM without messing around on an upstream repository. ;-)

Quote
I wish GitHub would provide native Mercurial support... that would be the dream :)

Maybe it's time for some people with a huge amount of time to create something universal you can switch to and from. ;)

@Laurent: Sorry if this goes a little bit off-topic. You may split up the topic, if you like. ;)
Title: My plans for the website tools
Post by: Laurent on March 22, 2011, 01:20:34 pm
Quote
Laurent, since you are already changing and reworking the web stuff, how about optional https support?

What do you mean?
Title: My plans for the website tools
Post by: Groogy on March 22, 2011, 01:42:31 pm
Quote from: "Laurent"
Quote
Laurent, since you are already changing and reworking the web stuff, how about optional https support?

What do you mean?


I was wondering that too =/
Title: My plans for the website tools
Post by: Klaim on March 22, 2011, 02:41:59 pm
Quote from: "Tank"
Quote from: "Klaim"
1. coherence of lexicon : the words used are not as intuitive as subversions and mercurial.

That's because you're used to them, and Subversion and Mercurial share a huge part of terminology. In Git there can't be a "git update", because you don't have a centralized server to update from. "update" means to fetch new commits, but since you always HAVE the repository on your harddrive, there's nothing to "update". Same goes with "git commit", where many people are confused because it doesn't "commit to the 'main' repository": It does what it says, commit your staged changes to YOUR repository. As soon as you've learned the fact, that you own a fully working and complete clone of the repository, things will get easier immediately.


That's not at all what I was meaning. Let me rephrase it : the natural (like in "not from by previous similar tool experience) way to express those concepts are not used in git. The wording is not well thought because it rely on the way git works internally but should have been thought to provide a "natural" (as much as we can) way to represent the ideas behind git, whatever the implementation.

Now, in Mercurial, update does not mean the same than in SVN, like for git. I'm not pointing a specific word and comparing to SVN, I'm saying that , as others have observed, the wording isn't as natural with git than in mercurial and bazaar. Even if both don't have the same semantic mapping than for Subversion.

But lets say it's a minor problem (even if it has cost).

Quote from: "Tank"

 
Quote
2. lack of feedback on errors : that can be a problem for "we don't have time for this shit" business - but that's ok for those who passed enough time studiying git to understand their errors easily

 That counts for every software, not only SCM. If there's an error you don't understand directly, you have to look it up. Happened many times before with me and Subversion due to strange behaviour (lockups, cleanups, the list is long).


No. That might be the norm on basic linux tools, yes, but it's not the norm at all. Most tools I use does report clear errors when something failed in a process. They don't "report nothing" and let you have to look for what happened. Not everyone have the time to understand those kind of things.

What's really dangerous is that if there is no error report, then sometimes you could do something wrong and not know it. That's really a problem.

Mercurial does report through the python-exception system, so most of the time the errors are full of informations that even if you don't understand them you can ask online easily by providing the error report.

It's common knowledge that following some public principles with git does avoid you almost any problem, so let's say it's not a real problem.

Quote from: "Tank"

 
Quote
3. complex manipulations are too complex : most of the problems with git arise when you use more than the 4 basic commands.

 I understand what you mean, but I think things get easier once you dive deeper. I love to compare this with Vim: When you start, you don't have to know the full commandset, only the basics to get you started. As times passes by, you may have the feeling of "Can't this be done more effectively?", then you fire up the docs and check if there's anything you can do better.
 
 Same goes with Git: You will probably do a lot of "revert stuff" manually in the beginning, or wild copying between your working copies. Later you get used to cherry-picking, rebasing, commit rework etc.


I agree. Still, learning have a cost. The problem arise in almost all business or even spare time : do I really need to spend lot of time on understanding this tool to make it useful? Git is expensive compared to Mercurial to learn, but both are more expensive than SVN.

So it's more a cost concern, as with any tool choice. :)

Quote from: "Tank"

 
Quote
4. Windows port has often been a problem (not sure it is still) because far from being stable.

 I can't tell you MUCH about this, however the times I've used Git on Windows it worked perfectly and didn't have any noticable problems (I used the CLI version aswell as TortoiseGit). But since I'm mainly on Linux, there're probably others who know this better.


You might have more informations about the windows case by reading the blog posts I pointed. I'm not a big user of Git, I use it mostly to clone repositories, so I know basic usage don't expose those problems.

Quote from: "Tank"

Quote
1. you're working with people that are familiar with git, so you choose git, or with mercurial so you choose it, etc.

You forget the part that says "The team has used SCM A, but after testing out B, they switched to SCM B." ;)


That happen, but not oftenat all. In our current case, I'm not sure that a lot of people understand the differences between Git and Mercurial, other than the alien-lexicon aspect. So, I guess that most of the time, a team will use one of those and not bother with others for years (like here with Git). That's fine as at least we don't have a clear killer-feater difference that makes one the obvious leader.

Quote from: "Tank"

Quote
There are differencies between git and mercurial that make them unperfect choice BOTH.

That's true, absolutely. Most SCM have their raison d'ĂȘtre. I wouldn't use Git on data that's huge and binary (like drawings), for example. But when talking about DSCM like Git, Mercurial and Bazaar, then my choice is made. ;)



No problem, we're not talking about personal choice here. It's more about what road did we gone through to get to this point. I'm looking for feedback, not flamewar ;)

By the way, Mercurial have the BigFiles extension that might become standard. One of the power of Mercurial is that it's really easy to extend. But it's less a toolbox than Git.

Quote from: "Tank"

Quote
Whatever you choose, understand that the cost of understanding git can be costly for some business.

Using something different or new always means that it costs time and breaks the "normal work" of a "business". The question is: Is that time well spent? For example, you only need 2 weeks to master Subversion, but 6 weeks to master Git. But if you're so much more productive with the latter, why shouldn't you invest the time? (replace Subversion and/or Git with anything, just an example)



Yes, I agree fully, as said before. Now, a lot of people say that Mercurial and Bazaar are lest costly than Git on time spent, but the difference are minor enough to make Git a good choice anyway. For me the real problem is that it's hard to tell for each project wich one will work better. So in the end, you might even use a dice to choose between Git and Mercurial... even if being on Windows might be big hint :)

Quote from: "Tank"

Quote
Anyway, choosing git or mercurial or any other is good, as far as it's decentralized. It really helps "lockfree" parallel work ;)

Definitely, yep. I want the power of an SCM without messing around on an upstream repository. ;-)


I'd like to use Git in a future project, after having use Mercurial a lot with my current ones. I think I'll get more points of coparison from that.

Quote from: "Tank"

Quote
I wish GitHub would provide native Mercurial support... that would be the dream :)

Maybe it's time for some people with a huge amount of time to create something universal you can switch to and from. ;)


I've made some research and event answered (successfully) about that on stackexchange. There is not current solution that match my personnal requirements.

But I guess some people are working on it :)
Title: My plans for the website tools
Post by: Svenstaro on March 22, 2011, 03:04:36 pm
Quote from: "Laurent"
Quote
Laurent, since you are already changing and reworking the web stuff, how about optional https support?

What do you mean?


Nevermind, I just realized this site can do https now. It kept redirecting me to http last time I tried.
Title: My plans for the website tools
Post by: Tank on March 22, 2011, 08:38:25 pm
To make something clear, at first: ;)
Quote
No problem, we're not talking about personal choice here. It's more about what road did we gone through to get to this point. I'm looking for feedback, not flamewar ;)

Same about here! It may happen that I sound rude sometimes. Don't take it personal, it's just my taste or arguing. ;)


Quote
The wording is not well thought because it rely on the way git works internally but should have been thought to provide a "natural" (as much as we can) way to represent the ideas behind git, whatever the implementation.

Okay, I see now what you were talking about. You're right, the Git terminology relies mostly on Git's own techniques and principles which is bad when you're looking over the whole (D)SCM land. But in this specific case, ergo when you're a Git user, it's perfect, because the terms describe the methods as best as possible.

However you're right, that makes things a little bit harder for newbies (like "What the heck means 'reset'?!" or "What's the index?!").

Quote

Quote from: "Tank"

 
Quote
2. lack of feedback on errors : that can be a problem for "we don't have time for this shit" business - but that's ok for those who passed enough time studiying git to understand their errors easily

 That counts for every software, not only SCM. If there's an error you don't understand directly, you have to look it up. Happened many times before with me and Subversion due to strange behaviour (lockups, cleanups, the list is long).

No. That might be the norm on basic linux tools, yes, but it's not the norm at all.

I have to request further, here: You mean the case that errors tell you nothing or that there aren't even ones? Then I guess you're not working with GNU/Linux? ;-) (it's a little bit funny right now, because in parallel I'm installing SP3 for Win XP and it just said "Error. Installation failed.", nothing more -- slapstick! ;)). Luckily most tools give you at least an idea of what went wrong. I was just regarding to Subversion in this case: The underlying toolset let me alone several times, having no clue what the h*ck went wrong.

Quote
Mercurial does report through the python-exception system, so most of the time the errors are full of informations that even if you don't understand them you can ask online easily by providing the error report.

Well, those exception reports are mostly only helpful for developers who're familiar with exactly that piece of code where the exception happened, otherwise it may take a long time. Can be sometimes compared to "Application crashed in 0x1234abcd, check the memory dump!" errors. ;) (especially when the error occurs deeply in external libraries due to wrong use) But, of course, better than nothing, and you can't provide foolproof and super-helpful error messages everywhere.

Quote
It's common knowledge that following some public principles with git does avoid you almost any problem, so let's say it's not a real problem.

I can just speak from my experience with Git: Even when you do something wrong, it's always recoverable (that also counts for other DSCM systems).

Quote
You might have more informations about the windows case by reading the blog posts I pointed. I'm not a big user of Git, I use it mostly to clone repositories, so I know basic usage don't expose those problems.

Well from time to time (every 4-8 weeks) I test my x-platform code on Windows to make sure everything still works. And of course the code often needs modifications to build and run properly. Therefore I'm even using Git on Windows for more than "git-clone" and hadn't have problems so far. But I'm not the reference here, of course. ;)

Quote
So, I guess that most of the time, a team will use one of those and not bother with others for years (like here with Git).

Sure, that's true. Changing something like the used SCM may be a bit task for bigger projects (you don't want to lose the history or any metadata you inserted into that system before). But it's more and more happening with Subversion (just like with SFML now) or CVS to name two. I agree that, for example, Mercurial or Git users won't change their systems to each other's, because both are doing fine.

Quote
That's fine as at least we don't have a clear killer-feater difference that makes one the obvious leader.

The killer feature is decentralized SCM, maybe together with an unmodifiable versioning history. And that's the reason why the folks are switching. ;)

Quote
For me the real problem is that it's hard to tell for each project wich one will work better. So in the end, you might even use a dice to choose between Git and Mercurial... even if being on Windows might be big hint :)

Yep, and to be honest: Everyboy has his favorite child that's 15 times better than anything else, quite normal. But reducing it to facts may have more than only THAT ONE option. ;)

Quote
I'd like to use Git in a future project, after having use Mercurial a lot with my current ones. I think I'll get more points of coparison from that.

You will love it. ;) I guess I should do something similar with Mercurial. Never hurts to think outside the box.
Title: My plans for the website tools
Post by: gsaurus on March 22, 2011, 08:42:46 pm
Sourceforge supports Git as well, why moving to Github?
I don't know the two platforms very well, so, just asking  :wink:
Title: My plans for the website tools
Post by: Laurent on March 22, 2011, 10:37:45 pm
Quote
Sourceforge supports Git as well, why moving to Github?

I think they support Git as a repository back-end, but their interface is not Git-oriented at all. And they look a little bit outdated compared to github or similar websites. Don't ask me why, it's just my personal feeling. I don't like it anymore.
Title: My plans for the website tools
Post by: Klaim on March 22, 2011, 10:41:45 pm
Quote
I have to request further, here: You mean the case that errors tell you nothing or that there aren't even ones? Then I guess you're not working with GNU/Linux?  (it's a little bit funny right now, because in parallel I'm installing SP3 for Win XP and it just said "Error. Installation failed.", nothing more -- slapstick! ). Luckily most tools give you at least an idea of what went wrong. I was just regarding to Subversion in this case: The underlying toolset let me alone several times, having no clue what the h*ck went wrong.


I'm using linux (Fedora) at my dayjob and Windows at home (with a Ubuntu box I use sometimes). Now I understand that the basic tools of linux doesn't return anything on success, but most of the time they still trigger a message on error.

So yes it's that basic message that is required. I recently heard that git's stability is better so maybe the time I'll really try it it'll be fine anyway.

Quote
Sourceforge supports Git as well, why moving to Github?


1. GitHub is simpler (visually)
2. Github is simpler to understand
3. Github is made for git, so all the features are built around the git features
4. Github is build around DSVC ideas that rely on project cloning. SourceForge just treat git repositories as any other repositories, while Github treat them as the camp fire around wich some people gather.

It's juste made in a better way for developing a project with a community.
Title: My plans for the website tools
Post by: Balder on March 23, 2011, 05:10:53 pm
...and sourceforge is Ad-Supported. Never liked the commercial feeling of it. Not to say that those ads are annoying; github has a cleaner interface.

We can even say the trend is moving from sourceforge to Git, not just now, since more than a year. Sourceforge didn't innovate much in these past years, and that's why it's getting "rusty", 'cause of sticking to the old ways when something better has been made, instead of adapting to that new thing. However this last comment was more a personal opinion rather than a fact.

Anyway, I love the changes too. Many thanks go to Laurent not just for keeping this up but to keep improving it!

Finally I hope these new tools will boost up the community so it can keep manteining this wonderful software that it's SFML.