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

Author Topic: My plans for the website tools  (Read 20438 times)

0 Members and 1 Guest are viewing this topic.

Svenstaro

  • Full Member
  • ***
  • Posts: 222
    • View Profile
My plans for the website tools
« Reply #30 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.

Arwel

  • Newbie
  • *
  • Posts: 19
    • View Profile
My plans for the website tools
« Reply #31 on: March 22, 2011, 10:05:20 am »
This is such a good news ! I can't wait to fork it !

Klaim

  • Full Member
  • ***
  • Posts: 137
    • View Profile
My plans for the website tools
« Reply #32 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 :)

Svenstaro

  • Full Member
  • ***
  • Posts: 222
    • View Profile
My plans for the website tools
« Reply #33 on: March 22, 2011, 12:29:34 pm »
Laurent, since you are already changing and reworking the web stuff, how about optional https support?

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
My plans for the website tools
« Reply #34 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. ;)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
My plans for the website tools
« Reply #35 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?
Laurent Gomila - SFML developer

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
My plans for the website tools
« Reply #36 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 =/
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Klaim

  • Full Member
  • ***
  • Posts: 137
    • View Profile
My plans for the website tools
« Reply #37 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 :)

Svenstaro

  • Full Member
  • ***
  • Posts: 222
    • View Profile
My plans for the website tools
« Reply #38 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.

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
My plans for the website tools
« Reply #39 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.

gsaurus

  • Sr. Member
  • ****
  • Posts: 262
    • View Profile
    • Evolution Engine
My plans for the website tools
« Reply #40 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:
Pluma - Plug-in Management Framework

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
My plans for the website tools
« Reply #41 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.
Laurent Gomila - SFML developer

Klaim

  • Full Member
  • ***
  • Posts: 137
    • View Profile
My plans for the website tools
« Reply #42 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.

Balder

  • Newbie
  • *
  • Posts: 26
    • View Profile
My plans for the website tools
« Reply #43 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.

 

anything