Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Klaim

Pages: 1 ... 7 8 [9]
121
General discussions / My plans for the website tools
« 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.

122
General discussions / My plans for the website tools
« 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 :)

123
General discussions / My plans for the website tools
« 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 :)

124
General discussions / My plans for the website tools
« 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 - 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.

125
General discussions / C++ scripting in SFML games
« on: March 20, 2011, 11:31:35 pm »
There are other alternatives. I know ChaiScript is made to be specifically done for C++. Falcon too is interesting, but for a big project, not for quick scripting system setup I guess.

126
General discussions / My plans for the website tools
« 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).

127
General discussions / Compo Preparation : Recent SFML 2.0 Stable Revision ?
« on: December 14, 2010, 02:00:59 pm »
Ok I'm in that case but it will not be a problem to use the static library as the compo will only produce prototypes, not final games. Thanks for pointing me this.

128
General discussions / Compo Preparation : Recent SFML 2.0 Stable Revision ?
« on: December 13, 2010, 11:37:09 pm »
Revision 1756 of https://sfml.svn.sourceforge.net/svnroot/sfml/branches/sfml2
, right?

Then thanks, I'll go with that.

129
SFML projects / Radiant Laser Cross
« on: December 13, 2010, 07:14:03 pm »
For the moment I work on this only when I'm fed up with my other projects so I'm not sure I'll have the collision system finished by the end of the year, but it's possible.

Once the collision system ready, adding an enemy system without scripting will be easy. But I'd like to add scripting (take a look at the TODO list ).

By the way, I started a shmup collision detection discussion on TIGSource that might be interesting for people around here : http://forums.tigsource.com/index.php?topic=15732.0

130
General discussions / Compo Preparation : Recent SFML 2.0 Stable Revision ?
« on: December 13, 2010, 06:52:31 pm »
Hi,

I'm preparing to participate to the next coming Ludum Dare competition (48h to make a game, this week end) and I want to use SFML 2.0. However it's not yet available as "stable" release.

So, if someone can point me to a recent 2.0 revision on svn that would be tested enough for me to build a basic game (I'll only have 48 hours after all), it would be helpful. I ask here before testing the last revision because I don't know if some current developpement added some temporary regression to the whole.

Once I start with a specific revision, I'll prepare to make me familar with it befor the event to be ready for showdown.

131
SFML projects / Radiant Laser Cross
« on: November 24, 2010, 10:42:51 am »
Hi, I'm making (when I'm tired about other projects) a kind of experimental shmup using SFML (1.6).

It's all open source, started as a 1 work-day week so it's currently badly coded but at least the player's ship gameplay works.

http://code.google.com/p/radiant-laser-cross/

There's a video of the current state in the link.

132
D / Anybody using DSFML/DSFML2?
« on: November 02, 2010, 05:20:35 pm »
Perfect! Thanks!

133
D / Anybody using DSFML/DSFML2?
« on: October 29, 2010, 09:04:19 pm »
Hi

I'm starting to get interested in trying to make something in D.

I wanted to use something like SFML so it's a good thing that there is a port!

Now I just need to know if it's compatible with the last dmd? I want to get with D2.

134
General discussions / How stable is the API for SFML 2.0 now?
« on: July 30, 2010, 08:35:32 pm »
Same questino here, I've used SFML 1.6 for a prototype (will post about it soon) but I'm really interested in the new version for other prototypes so I'd like to know if I can already help by using the current 2.0 trunk or is it too early?

Pages: 1 ... 7 8 [9]
anything