2010/6/12 Enrico Tröger enrico.troeger@uvena.de:
On Wed, 9 Jun 2010 17:09:49 +0100, Nick wrote:
On Wed, 09 Jun 2010 15:11:48 +0200 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 09.06.2010 03:40, schrieb Lex Trotman:
Sure its easier if everyone is using git, but ATM this is an SVN project.
Although most, if not all, geany developers use git, don't they?
Do you mean git-svn? The Git repo is not writable.
I don't use Git for Geany, but wouldn't mind if everyone else wants to switch to it.
Me neither. If we want, we can switch to GIT.
Since my experience with GIT is very limited so far, I don't mind which way we want to go and how to organise the repository regarding branch strategies and such. The only requirement/wish I have that we don't host the repository on gitorious or github or such social coding platforms, that sucks.
Well, I have no experience with repo.or.cz, but my feeling is that this is just a "classical" type of hosting where contributors cannot easily create their own clones and have them hosted. Myself I'm a hater of anything that has "social" in its title and all the chatting nonsense (facebook, skype, ICQ to name some), but gitorious and github are much more "useful" than "social".
This choice will also influence the workflow in which you will use git. If contributors cannot have their branches hosted easily, then the the Linus model (one pusher pulling from contributors) will be harder to realize.
Regards,
Jiri
Sorry to serial post, I didn't see that Enrico had already replied.
On 13 June 2010 05:30, Jiří Techet techet@gmail.com wrote:
2010/6/12 Enrico Tröger enrico.troeger@uvena.de:
On Wed, 9 Jun 2010 17:09:49 +0100, Nick wrote:
On Wed, 09 Jun 2010 15:11:48 +0200 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 09.06.2010 03:40, schrieb Lex Trotman:
Sure its easier if everyone is using git, but ATM this is an SVN project.
Although most, if not all, geany developers use git, don't they?
Do you mean git-svn? The Git repo is not writable.
I don't use Git for Geany, but wouldn't mind if everyone else wants to switch to it.
Me neither. If we want, we can switch to GIT.
Since my experience with GIT is very limited so far, I don't mind which way we want to go and how to organise the repository regarding branch strategies and such. The only requirement/wish I have that we don't host the repository on gitorious or github or such social coding platforms, that sucks.
Well, I have no experience with repo.or.cz, but my feeling is that this is just a "classical" type of hosting where contributors cannot easily create their own clones and have them hosted.
Yes, I can't see where you can set up cloned repos except as complete new projects. Also AFAICT Sourceforge only allows them to be created by shell access
To me, letting anyone create public cloned branches without bothering the project maintainers is one of the major features to look for. As an example consider the current session management situation, one option is in a branch which the maintainers had to allow, one is a set of patches. With the cloned branch feature both Eugene and Ditmar could have created their own branch repo, without bothering Nick/Enrico, and made their changes visible so others could just grab their repos by git clone, try them and keep their local branch up to date by git pull.
Then they might be merged, or one chosen and pulled into the main repo, thats a non-technical question, but the VCS and host don't get in the way.
Communication would be still via the geany-devel mailing list, you don't need to use any of the other features.
As I'm looking at potential hosting services for the first time, Gitorious and Github don't actually look to me to be any more socially oriented than sourceforge, both seem to emphasise hosting and then offer other apps as well just like sourceforge. Certainly their public face tries to be friendlier whereas sourceforge is a bit austere, but thats probably because they are just newer and trying to increase their patronage.
Myself I'm a
hater of anything that has "social" in its title and all the chatting nonsense (facebook, skype, ICQ to name some
+1 :)
), but gitorious and github
are much more "useful" than "social".
This choice will also influence the workflow in which you will use git. If contributors cannot have their branches hosted easily, then the the Linus model (one pusher pulling from contributors) will be harder to realize.
In fact without it, the equivalent of SVN branches for long lived changes is harder. Either the maintainers have to set up a new repo or the contributor has to set up a complete new project. Very few people can or would want to make their local repo available publicly.
Cheers Lex
Regards,
Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sun, 13 Jun 2010 10:05:26 +1000, Lex wrote:
As I'm looking at potential hosting services for the first time, Gitorious and Github don't actually look to me to be any more socially oriented than sourceforge, both seem to emphasise hosting and then offer other apps as well just like sourceforge. Certainly their public face tries to be friendlier whereas sourceforge is a bit
"friendlier"? Really? To me they seem bloated and sort of unusable. github's interface is totally unusable, the dynamic loading of the directory contents sucks and the overall usage of their repo browser is awful, IMHO. Similar for gitorious though it's not as bad as github.
In fact, I do like Sourceforge's plainness or better, the plainness of git-web. Also, IMO cgit is a completely sufficient web interface.
Ok, this was only about the git web interface of the hosing services but still. I really don't like github and gitorious. Also, as I said I'm not that familiar with GIT but I don't see why features like forking or such should be done by a hosting service, aren't these all features of the VCS itself?
Regards, Enrico
I have a few years of daily experience both with SVN and GIT. We use SVN at work and I use GIT for all my personal projects. I like GIT better than SVN.
In my humble opinion you shouldn't switch unless you are unhappy with sourceforge / svn.
2010/6/13 Enrico Tröger enrico.troeger@uvena.de:
On Sun, 13 Jun 2010 10:05:26 +1000, Lex wrote:
As I'm looking at potential hosting services for the first time, Gitorious and Github don't actually look to me to be any more socially oriented than sourceforge, both seem to emphasise hosting and then offer other apps as well just like sourceforge. Certainly their public face tries to be friendlier whereas sourceforge is a bit
"friendlier"? Really? To me they seem bloated and sort of unusable. github's interface is totally unusable, the dynamic loading of the directory contents sucks and the overall usage of their repo browser is awful, IMHO. Similar for gitorious though it's not as bad as github.
Ok, this was only about the git web interface of the hosing services but still. I really don't like github and gitorious. Also, as I said I'm not that familiar with GIT but I don't see why features like forking or such should be done by a hosting service, aren't these all features of the VCS itself?
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sun, 13 Jun 2010 14:01:02 +0200 Daniel Marjamäki daniel.marjamaki@gmail.com wrote:
I have a few years of daily experience both with SVN and GIT. We use SVN at work and I use GIT for all my personal projects. I like GIT better than SVN.
In my humble opinion you shouldn't switch unless you are unhappy with sourceforge / svn.
I agree. For our current development process I don't see any big need to change away from SVN. It will cost a lot of effort with no extra profit adding.
Cheers, Frank
On Sun, 13 Jun 2010 14:11:05 +0200% Frank Lanitz frank@frank.uvena.de wrote:
On Sun, 13 Jun 2010 14:01:02 +0200 Daniel Marjamäki daniel.marjamaki@gmail.com wrote:
I have a few years of daily experience both with SVN and GIT. We use SVN at work and I use GIT for all my personal projects. I like GIT better than SVN.
In my humble opinion you shouldn't switch unless you are unhappy with sourceforge / svn.
I agree. For our current development process I don't see any big need to change away from SVN. It will cost a lot of effort with no extra profit adding.
I'd like to second that. And, while I use local Git repository for Geany, I'm completely happy with git-svn (and my separate SVN branch, of course :).
Best regards, Eugene.
On Sun, 13 Jun 2010 16:14:57 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Sun, 13 Jun 2010 14:11:05 +0200% Frank Lanitz frank@frank.uvena.de wrote:
On Sun, 13 Jun 2010 14:01:02 +0200 Daniel Marjamäki daniel.marjamaki@gmail.com wrote:
I have a few years of daily experience both with SVN and GIT. We use SVN at work and I use GIT for all my personal projects. I like GIT better than SVN.
In my humble opinion you shouldn't switch unless you are unhappy with sourceforge / svn.
I agree. For our current development process I don't see any big need to change away from SVN. It will cost a lot of effort with no extra profit adding.
I'd like to second that. And, while I use local Git repository for Geany, I'm completely happy with git-svn (and my separate SVN branch, of course :).
I agree. Same here.
Cheers, Frank
On Sun, 13 Jun 2010 14:17:54 +0200, Frank wrote:
On Sun, 13 Jun 2010 16:14:57 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Sun, 13 Jun 2010 14:11:05 +0200% Frank Lanitz frank@frank.uvena.de wrote:
On Sun, 13 Jun 2010 14:01:02 +0200 Daniel Marjamäki daniel.marjamaki@gmail.com wrote:
I have a few years of daily experience both with SVN and GIT. We use SVN at work and I use GIT for all my personal projects. I like GIT better than SVN.
In my humble opinion you shouldn't switch unless you are unhappy with sourceforge / svn.
I agree. For our current development process I don't see any big need to change away from SVN. It will cost a lot of effort with no extra profit adding.
I'd like to second that. And, while I use local Git repository for Geany, I'm completely happy with git-svn (and my separate SVN branch, of course :).
I agree. Same here.
Well, if Frank doesn't want to and Nick doesn't mind, we maybe can indeed save us the whole trouble of discussing about switching :).
Btw, my personal opinion on switching or not doesn't count much at all. The amount of future commits by me will be very small.
Regards, Enrico
Am 13.06.2010 14:22, schrieb Enrico Tröger:
Well, if Frank doesn't want to and Nick doesn't mind, we maybe can indeed save us the whole trouble of discussing about switching :).
Btw, my personal opinion on switching or not doesn't count much at all. The amount of future commits by me will be very small.
Regards, Enrico
What would switching actually involve? We could just take over the git mirror which contains the svn history as well, so I expect the actual switch to be little work.
IMO sticking to svn doesn't make sense considering that most contributors seem to use git (and git-svn). git-svn has a lot of drawbacks and its slowness is hugely annoying especially when paired with the slow sf svn servers for me. I am generally unhappy with svn and git-svn.
Best regards.
On Sun, Jun 13, 2010 at 14:38, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 13.06.2010 14:22, schrieb Enrico Tröger:
Well, if Frank doesn't want to and Nick doesn't mind, we maybe can indeed save us the whole trouble of discussing about switching :).
Btw, my personal opinion on switching or not doesn't count much at all. The amount of future commits by me will be very small.
Regards, Enrico
What would switching actually involve? We could just take over the git mirror which contains the svn history as well, so I expect the actual switch to be little work.
Tags and branches are missing in the git mirror. But it's easy to google out how to completely migrate the svn repository to git.
Jiri
On Sun, 13 Jun 2010 23:18:45 +0200 Jiří Techet techet@gmail.com wrote:
On Sun, Jun 13, 2010 at 14:38, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 13.06.2010 14:22, schrieb Enrico Tröger:
Well, if Frank doesn't want to and Nick doesn't mind, we maybe can indeed save us the whole trouble of discussing about switching :).
Btw, my personal opinion on switching or not doesn't count much at all. The amount of future commits by me will be very small.
Regards, Enrico
What would switching actually involve? We could just take over the git mirror which contains the svn history as well, so I expect the actual switch to be little work.
Tags and branches are missing in the git mirror. But it's easy to google out how to completely migrate the svn repository to git.
Below is a small bash script I found online sometime back for purposes of migrating svn debian package repositories to git. It can be modified (remove the "debian/" from git tag) for purposes of porting the tags over.
#!/bin/bash
for branch in `git branch -r`; do if [ `echo $branch | egrep "tags/.+$"` ]; then version=`basename $branch` subject=`git log -1 --pretty=format:"%s" $branch` export GIT_COMMITTER_DATE=`git log -1 --pretty=format:"%ci" $branch`
echo "Tag $version [Y/n]?" read yesno if [ -z $yesno ] || [ $yesno = "Y" ]; then git tag -s -f -m "$subject" "debian/$version" "$branch^" git branch -d -r $branch fi fi done
On Sun, 13 Jun 2010 14:22:05 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
I have a few years of daily experience both with SVN and GIT. We use SVN at work and I use GIT for all my personal projects. I like GIT better than SVN.
In my humble opinion you shouldn't switch unless you are unhappy with sourceforge / svn.
I agree. For our current development process I don't see any big need to change away from SVN. It will cost a lot of effort with no extra profit adding.
I'd like to second that. And, while I use local Git repository for Geany, I'm completely happy with git-svn (and my separate SVN branch, of course :).
I agree. Same here.
Well, if Frank doesn't want to and Nick doesn't mind, we maybe can indeed save us the whole trouble of discussing about switching :).
To be honest, it would be some hassle for me to switch. I only have experience using Git locally, no push/pull/branches. But that experience was great, I like the tool.
So I think as Lex has suggested, that we shouldn't switch right now. Maybe some time in the future. I don't have time ATM to learn Git/investigate switching.
Also as regards sourceforge, I agree with Enrico that we want to stay with them for now at least.
Regards, Nick
On Tue, Jun 15, 2010 at 17:42, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Sun, 13 Jun 2010 14:22:05 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
I have a few years of daily experience both with SVN and GIT. We use SVN at work and I use GIT for all my personal projects. I like GIT better than SVN.
In my humble opinion you shouldn't switch unless you are unhappy with sourceforge / svn.
I agree. For our current development process I don't see any big need to change away from SVN. It will cost a lot of effort with no extra profit adding.
I'd like to second that. And, while I use local Git repository for Geany, I'm completely happy with git-svn (and my separate SVN branch, of course :).
I agree. Same here.
Well, if Frank doesn't want to and Nick doesn't mind, we maybe can indeed save us the whole trouble of discussing about switching :).
To be honest, it would be some hassle for me to switch. I only have experience using Git locally, no push/pull/branches. But that experience was great, I like the tool.
So I think as Lex has suggested, that we shouldn't switch right now. Maybe some time in the future. I don't have time ATM to learn Git/investigate switching.
Also as regards sourceforge, I agree with Enrico that we want to stay with them for now at least.
Just for those interested, I have created a complete import of your SVN repo to git. The result is here:
http://gitorious.org/geany/complete
It contains all the branches and all the tags you have created (many of the branches could be deleted I guess) and the whole history since 2005. Here's what I did (may be useful if you decide to migrate to git in the future). Basically I followed the instructions here:
http://blog.woobling.org/2009/06/git-svn-abandon.html
and downloaded the conversion scripts.
1. You have to create the authors file with names and email addresses of the committers. Each line has the form:
committer = full name email@address.com
This was easy because most of them are already present in your git mirror. The missing ones were:
(no author) clytie kretek statc
"(no author)" was used for the initial import so I used Enrico here. I think I found the correct name and email for "clytie", but I had no idea for kretek and statc so I used just a fake name and email for them.
2. Run
git svn clone --authors-file=authors.txt --prefix=svn/ --stdlayout https://geany.svn.sourceforge.net/svnroot/geany
(wait about 90 minutes until everything gets downloaded)
3. Make proper tags and branches:
cd geany git svn-abandon-fix-refs git svn-abandon-cleanup
The result could probably be manually improved for some merges but I don't know if it's worth the work.
4. Push the result:
git remote add origin git@gitorious.org:geany/complete.git git push --all git push --tags
That's it.
Just a few more comments related to the possible switch. First, just an observation - the people who said they don't mind are those who have write access to SVN. I agree that for them the switch is much less important - they can create their branches to develop and back up the work in progress and for their own development the current workflow is OK. The current situation is worse for external contributors who don't submit their patches so often to have SVN access. They either don't have their work backed up, or they have to create their own repository e.g. at gitorious as I did. When they finish their work, they can't just tell "please pull from here" but have to submit their patches by email. This is harder for the maintainers too - they have to manually apply the patches from the email instead of just "git pull". Finally, it will be the maintainer who makes the commit and the information about the original committer is lost with SVN - with git you see every single commit author (this means you have to add some "thanks to" to the commit message for SVN - this work would be eliminated with git). Finally, you can forget about updating ChangeLog - this can be generated automatically by git (GNOME libraries usually have one pre-git ChangeLog and then a changelog automatically generated from the git history during "make distcheck"). So what I want to say here is that while the core developer's development work won't be affected by the switch much, the collaboration with external developers will improve considerably.
On the other hand you are right - git is a bit harder to use and there will be many "doh" moments. The learning curve is steeper that with SVN but when you learn it (I really don't want to make an impression I'm an expert here - git still surprises me sometimes), you'll realize git is a very powerful and helpful tool.
There has been some discussion about changing the bug tracker at the same time - I would make it an independent issue. My personal opinion is that you should just stay with sourceforge - moving the whole bug tracker somewhere else is too much manual work rewarded by too little gain.
Cheers,
Jiri
I wholeheartedly agree on all of your points!
Best regards.
<snip>
Just a few more comments related to the possible switch. First, just an observation - the people who said they don't mind are those who have write access to SVN.
Thats a fair comment, probably because they are the ones who will be most affected by the change, who will use it the most, and will have to change their workflow the most. Humans don't like change, even (or especially) programmers who are exposed to lots of it.
I agree that for them the switch is much
less important - they can create their branches to develop and back up the work in progress and for their own development the current workflow is OK. The current situation is worse for external contributors who don't submit their patches so often to have SVN access. They either don't have their work backed up, or they have to create their own repository e.g. at gitorious as I did. When they finish their work, they can't just tell "please pull from here" but have to submit their patches by email. This is harder for the maintainers too - they have to manually apply the patches from the email instead of just "git pull".
This workflow is only likely when changes are submitted by well known and experienced submitters. Otherwise it will be import to local clone, check and edit it some, then commit and push upstream, so the problems you describe below will still exist AFAICT. Many patches get the response, "committed but I changed xxx". Also you don't want to pull every daily backup commit from the user into the main repository.
Finally, it will be the maintainer
who makes the commit and the information about the original committer is lost with SVN - with git you see every single commit author (this means you have to add some "thanks to" to the commit message for SVN - this work would be eliminated with git). Finally, you can forget about updating ChangeLog - this can be generated automatically by git (GNOME libraries usually have one pre-git ChangeLog and then a changelog automatically generated from the git history during "make distcheck"). So what I want to say here is that while the core developer's development work won't be affected by the switch much, the collaboration with external developers will improve considerably.
On the other hand you are right - git is a bit harder to use and there will be many "doh" moments. The learning curve is steeper that with SVN but when you learn it (I really don't want to make an impression I'm an expert here - git still surprises me sometimes),
Now thats the last thing you want from a VCS, surprise, what you want is stability, ease of use and simplicity, power and speed are nice to haves only if the preceding are there.
I understand from reading the Advanced Git book that it is reasonably hard to actually lose data, but it also looks rather hard to recover from a mistake by an inexperienced user.
you'll realize
git is a very powerful and helpful tool.
There has been some discussion about changing the bug tracker at the same time - I would make it an independent issue. My personal opinion is that you should just stay with sourceforge - moving the whole bug tracker somewhere else is too much manual work rewarded by too little gain.
Good point.
Cheers Lex
Cheers,
Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, Jun 17, 2010 at 00:38, Lex Trotman elextr@gmail.com wrote:
<snip>
Just a few more comments related to the possible switch. First, just an observation - the people who said they don't mind are those who have write access to SVN.
Thats a fair comment, probably because they are the ones who will be most affected by the change, who will use it the most, and will have to change their workflow the most. Humans don't like change, even (or especially) programmers who are exposed to lots of it.
That's a fair comment too. It really depends on the percentage of work being done by the core developers. If the number of patches coming from outside is marginal, then the time savings gained by switching to git are marginal too and vice versa. On the other hand, you might get more external contributors if you make it easier for them to submit patches by switching to git - but these are only speculations of course.
I agree that for them the switch is much
less important - they can create their branches to develop and back up the work in progress and for their own development the current workflow is OK. The current situation is worse for external contributors who don't submit their patches so often to have SVN access. They either don't have their work backed up, or they have to create their own repository e.g. at gitorious as I did. When they finish their work, they can't just tell "please pull from here" but have to submit their patches by email. This is harder for the maintainers too - they have to manually apply the patches from the email instead of just "git pull".
This workflow is only likely when changes are submitted by well known and experienced submitters. Otherwise it will be import to local clone, check and edit it some, then commit and push upstream, so the problems you describe below will still exist AFAICT. Many patches get
Depends what you do with it. You can keep the contributor's commits and just add your commit with fixes. Or you can rebase and squash the fixes with the contributor's commits. You can also chose if you make the commit as yourself or as the contributor. You have just more freedom.
the response, "committed but I changed xxx". Also you don't want to pull every daily backup commit from the user into the main repository.
Sure, the contributor should tell you when he's done and request the pull only when the code is in a reasonable state. He might also consider squashing the commits in his history so you don't see his "internal" bugfixes.
Finally, it will be the maintainer
who makes the commit and the information about the original committer is lost with SVN - with git you see every single commit author (this means you have to add some "thanks to" to the commit message for SVN - this work would be eliminated with git). Finally, you can forget about updating ChangeLog - this can be generated automatically by git (GNOME libraries usually have one pre-git ChangeLog and then a changelog automatically generated from the git history during "make distcheck"). So what I want to say here is that while the core developer's development work won't be affected by the switch much, the collaboration with external developers will improve considerably.
On the other hand you are right - git is a bit harder to use and there will be many "doh" moments. The learning curve is steeper that with SVN but when you learn it (I really don't want to make an impression I'm an expert here - git still surprises me sometimes),
Now thats the last thing you want from a VCS, surprise, what you want is stability, ease of use and simplicity, power and speed are nice to haves only if the preceding are there.
Totally agree and this was exactly my point. I was trying to mention all positive things I see about git and all the negatives as well - all of them have to be taken into account. The positives are clear and from the negatives I see only the effort spent to convert the SVN repository to git (this is where I tried to help a bit) and then the transitional time until everyone gets used to git and the slightly different way of doing things.
I understand from reading the Advanced Git book that it is reasonably hard to actually lose data, but it also looks rather hard to recover from a mistake by an inexperienced user.
Depends how the repository you push to is set up. For GNOME git repositories the master branch cannot be "undone". But you can (fortunately) delete other branches so this is where you could lose data. But remember that git is a distributed VCS so if you do something really disastrous, there is a very good chance that someone else has cloned or pulled recently and he can provide his clone for the recovery. (Say goodbye to your SVN history if the sourceforge servers get corrupted and you don't have a backup. With git you don't care - you and many others have more or less up to date clone of it.)
Cheers,
Jiri
On Wed, 16 Jun 2010 13:21:49 +0200 Jiří Techet techet@gmail.com wrote:
On Tue, Jun 15, 2010 at 17:42, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Sun, 13 Jun 2010 14:22:05 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
> I have a few years of daily experience both with SVN and > GIT. We use SVN at work and I use GIT for all my personal > projects. I like GIT better than SVN. > > In my humble opinion you shouldn't switch unless you are > unhappy with sourceforge / svn.
I agree. For our current development process I don't see any big need to change away from SVN. It will cost a lot of effort with no extra profit adding.
I'd like to second that. And, while I use local Git repository for Geany, I'm completely happy with git-svn (and my separate SVN branch, of course :).
I agree. Same here.
Well, if Frank doesn't want to and Nick doesn't mind, we maybe can indeed save us the whole trouble of discussing about switching :).
To be honest, it would be some hassle for me to switch. I only have experience using Git locally, no push/pull/branches. But that experience was great, I like the tool.
So I think as Lex has suggested, that we shouldn't switch right now. Maybe some time in the future. I don't have time ATM to learn Git/investigate switching.
Also as regards sourceforge, I agree with Enrico that we want to stay with them for now at least.
Just for those interested, I have created a complete import of your SVN repo to git. The result is here:
Nice.
- You have to create the authors file with names and email addresses
of the committers. Each line has the form:
committer = full name email@address.com
This was easy because most of them are already present in your git mirror. The missing ones were:
kretek
Is an old nick of mine.
Cheers, Frank
On Tue, 15 Jun 2010 16:42:56 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On Sun, 13 Jun 2010 14:22:05 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
I have a few years of daily experience both with SVN and GIT. We use SVN at work and I use GIT for all my personal projects. I like GIT better than SVN.
In my humble opinion you shouldn't switch unless you are unhappy with sourceforge / svn.
I agree. For our current development process I don't see any big need to change away from SVN. It will cost a lot of effort with no extra profit adding.
I'd like to second that. And, while I use local Git repository for Geany, I'm completely happy with git-svn (and my separate SVN branch, of course :).
I agree. Same here.
Well, if Frank doesn't want to and Nick doesn't mind, we maybe can indeed save us the whole trouble of discussing about switching :).
To be honest, it would be some hassle for me to switch. I only have experience using Git locally, no push/pull/branches. But that experience was great, I like the tool.
So I think as Lex has suggested, that we shouldn't switch right now. Maybe some time in the future. I don't have time ATM to learn Git/investigate switching.
Also as regards sourceforge, I agree with Enrico that we want to stay with them for now at least.
I completely second this.
Cheers, Frank
Am 13.06.2010 14:11, schrieb Frank Lanitz:
I agree. For our current development process I don't see any big need to change away from SVN. It will cost a lot of effort with no extra profit adding.
Are you sure? I don't think it'll cost much, but it would make working on Geany easier for the git using contributors (which seems to be the majority).
The switch makes only sense if more people are using git than svn. If that's not true than we should stick to svn. But if it is, then most people need work arounds which only increase the house-keeping work (meaning there's less time to do actual coding).
Best regards.
Am 13.06.2010 13:08, schrieb Enrico Tröger:
I really don't like github and gitorious. Also, as I said I'm not that familiar with GIT but I don't see why features like forking or such should be done by a hosting service, aren't these all features of the VCS itself?
Yes and no. Forking at the hoster side has several advantages. You get a free host for the remote, the forks are categorized and associated with the mainline, the actual changes in the fork are visible for anyone (most importantly for the maintainers of mainline). And you get the forks of several contributors collected in a single place making it easier for people to pick out their favorite changes etc.
Best regards.
On Sun, 13 Jun 2010 14:42:03 +0200 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 13.06.2010 13:08, schrieb Enrico Tröger:
I really don't like github and gitorious. Also, as I said I'm not that familiar with GIT but I don't see why features like forking or such should be done by a hosting service, aren't these all features of the VCS itself?
Yes and no. Forking at the hoster side has several advantages. You get a free host for the remote, the forks are categorized and associated with the mainline, the actual changes in the fork are visible for anyone (most importantly for the maintainers of mainline). And you get the forks of several contributors collected in a single place making it easier for people to pick out their favorite changes etc.
This could also be done by a self-hosted solution as in most cases the local branch/folk is knowing of its parents.
Cheers, Frank
On Sun, 13 Jun 2010 13:08:33 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Sun, 13 Jun 2010 10:05:26 +1000, Lex wrote:
As I'm looking at potential hosting services for the first time, Gitorious and Github don't actually look to me to be any more socially oriented than sourceforge, both seem to emphasise hosting and then offer other apps as well just like sourceforge. Certainly their public face tries to be friendlier whereas sourceforge is a bit
"friendlier"? Really? To me they seem bloated and sort of unusable. github's interface is totally unusable, the dynamic loading of the directory contents sucks and the overall usage of their repo browser is awful, IMHO. Similar for gitorious though it's not as bad as github.
In fact, I do like Sourceforge's plainness or better, the plainness of git-web. Also, IMO cgit is a completely sufficient web interface.
Ok, this was only about the git web interface of the hosing services but still. I really don't like github and gitorious. Also, as I said I'm not that familiar with GIT but I don't see why features like forking or such should be done by a hosting service, aren't these all features of the VCS itself?
Bandwidth issues. If your connection to your git host sucks (sourceforge.net particularly sucks from Asian countries) then you want to minimize data transfer as much as possible. To clone one repository locally, and then push everything back up involves a significantly larger amount of data transfer than having a branch already cloned remotely, and pushing only the new hashes up.
Right now, svn sucks so hard over here that I cannot do a svn checkout from a sourceforge.net hosted mirror without having my connection interrupted. What I end up doing is using my shell account on alioth.debian.net to git svn clone, then git repack -ad to pack it as small as possible, and rsync over the .git directory. And because git-svn is not perfect, I sometimes end up with a repository that is no longer able to dcommit, and have to repeat those steps. That said, I don't actually commit anything to geany, only geany-plugins.
On Sun, Jun 13, 2010 at 17:38, Chow Loong Jin hyperair@gmail.com wrote:
Bandwidth issues. If your connection to your git host sucks (sourceforge.net particularly sucks from Asian countries) then you want
Sourceforge tends to have "bad days" here too (Czech Republic) - I suspect it's a global problem. (From my experience so far, gitorious works very well here.) One more reason for having an alternative mirror.
Jiri
To reply to several previous posts.
- Remotely hosted branches: gitorious.org/github.com can be very useful for these, no matter how much you hate them. It'd be worth having a mirror of Geany on gitorious.org/github.com to allow for users to perform remote-cloning and pushing of new commits, so that you can either rebase or merge these back into the main tree hosted at sourceforge.net.
I see that ability for anyone to create visible branches that can be easily tested by anyone as the main improvement that switching to Git would give. And teh project admins don't need to do anything to enable them (unless on sourceforge).
Note that in reality the workflow for patches not pushed directly by contributors with commit rights, is that they are applied in someones local working directory checked, edited and then committed and pushed, almost never would such changes be direct to the master repo.
Sourceforge tends to have "bad days" here too (Czech Republic) - I suspect it's a global problem. (From my experience so far, gitorious works very well here.) One more reason for having an alternative mirror.
SVN seems to work much better here (Australia) lately, maybe its backbone upgrades or that the ISP upgraded my ADSL speed, it used to have horrendous days.
For me there is the one possible advantage for Git, but as of now I'm happy either way, I can go on using SVN to the repo and git locally.
I guess we should also consider that no matter how easy we think it will be there will probably be some disruption during the changeover so it should be now (immediately after a release) or not until the next release, which I think is probably better so that the hosting and workflow issues can be worked through some more. Jiri, hold that Gitorious project to keep out cyber squatters.
Cheers Lex
Am 14.06.2010 03:58, schrieb Lex Trotman:
I guess we should also consider that no matter how easy we think it will be there will probably be some disruption during the changeover so it should be now (immediately after a release) or not until the next release, which I think is probably better so that the hosting and workflow issues can be worked through some more. Jiri, hold that Gitorious project to keep out cyber squatters.
0.19 is just out, why wait for the next release? 0.19 is so recent, waiting for the next release will have no advantage (because we are in the same situation then as today). Can you elaborate that please?
Best regards.
On 14 June 2010 15:41, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 14.06.2010 03:58, schrieb Lex Trotman:
I guess we should also consider that no matter how easy we think it will be there will probably be some disruption during the changeover so it should be now (immediately after a release) or not until the next release, which I think is probably better so that the hosting and workflow issues can be worked through some more. Jiri, hold that Gitorious project to keep out cyber squatters.
0.19 is just out, why wait for the next release? 0.19 is so recent, waiting for the next release will have no advantage (because we are in the same situation then as today). Can you elaborate that please?
Hi Thomas,
Sure, multi part answer.
1. Yes you are right, it doesn't have to be *immediately* after a release, just before the heavy activity approaching a release.
2. What might be better if there is some delay?
Because I don't think we have got a good handle on host, bug tracker etc. The responses were far from unanimous for a switch to Git, though no one was heavily against it.
As far as I can tell Jiri is the only one who has responded who has actual experience running a Git project and that is only on Gitoroius. So I'd ask:
* Does anyone else run a Git project, which host and whats the experience? * How many people contribute to one, and what hosting service do they use and what is the experience, is performance consistent and better than Sourceforge SVN, all around the world? * And does anyone have experience using any other DVCS and hosting service that would make them recommend it, or recommend against it? * should the bug tracker be moved? Can it be done without losing anything?
There are rather a lot of options listed here: https://git.wiki.kernel.org/index.php/GitHosting Has anyone used any?
The important things we need to know about a hosting service are: * likely stability, some have gone offline during the GFC, but this is hard to judge * performance for a good range of users in a good range of locations * reliability, low downtime * features, hosting clones, bug tracking ?????
My answer is that I only run Git locally, so I cannot add any information.
Who can? I'm happy to collate the replies.
So far, Jiri I take it you are happy with Gitorious, it has the features, but some don't like its style, does anyone have performance problems with it? Whats its reliability like?
For Github, some really don't like its style :-)
Cheers Lex
Best regards. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
I cannot answer any of the questions because I also have no experience in running a git project.
But what I know is that we are actually less depending on a hoster. Because of git's DVCS nature, everyone has the complete repo locally and can work offline with it. Git hosting is something for convinience (i.e. web interface for source browsing). We wouldn't actually *need* a hoster at all, but of course it would be nice (with hosting, cloning other people's repos is simplified extremely).
This is one of the strong points of git. Even if the hoster is not very dependable, since the actual repo is on everyone's system, the hoster could be dead for a few days or we could switch the hoster easily without losing anything.
Best regards.
On 14 June 2010 18:16, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
I cannot answer any of the questions because I also have no experience in running a git project.
But what I know is that we are actually less depending on a hoster. Because of git's DVCS nature, everyone has the complete repo locally and can work offline with it.
You are right it is slightly less dependent since all clones have the history, but see below.
Git hosting is something for convinience (i.e. web
interface for source browsing). We wouldn't actually *need* a hoster at all, but of course it would be nice (with hosting, cloning other people's repos is simplified extremely).
Well, you will never find my repo as I don't have a static IP address, and as I have limits on bandwidth and volume I am not going to allow anyone to access it even if I had a static address and finally ADSL upload speeds are a lot slower than downloads. That is what hosting services are for. I suspect a lot of contributors are in the same boat, so, without the host, sharing would actually be hard.
This is one of the strong points of git. Even if the hoster is not very dependable, since the actual repo is on everyone's system, the hoster could be dead for a few days or we could switch the hoster easily without losing anything.
Except a lot of time and energy that could have gone into actual coding instead of setting up another %^&*$#@@ repository :-)
Cheers Lex
Best regards.
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 14 Jun 2010 10:16:17 +0200 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
I cannot answer any of the questions because I also have no experience in running a git project.
But what I know is that we are actually less depending on a hoster. Because of git's DVCS nature, everyone has the complete repo locally and can work offline with it. Git hosting is something for convinience (i.e. web interface for source browsing). We wouldn't actually *need* a hoster at all, but of course it would be nice (with hosting, cloning other people's repos is simplified extremely).
This is one of the strong points of git. Even if the hoster is not very dependable, since the actual repo is on everyone's system, the hoster could be dead for a few days or we could switch the hoster easily without losing anything.
That's true. However you cannot host-switch the master tree for a project each week ;)
Cheers, Frank
On Sat, 19 Jun 2010 17:55:09 +0200 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 19.06.2010 17:50, schrieb Frank Lanitz:
That's true. However you cannot host-switch the master tree for a project each week ;)
You sure can.
Well, I'm afraid users will not honor that ;)
Cheers, Frank
Am 19.06.2010 17:56, schrieb Frank Lanitz:
On Sat, 19 Jun 2010 17:55:09 +0200 Thomas Martitzthomas.martitz@student.htw-berlin.de wrote:
Am 19.06.2010 17:50, schrieb Frank Lanitz:
That's true. However you cannot host-switch the master tree for a project each week ;)
You sure can.
Well, I'm afraid users will not honor that ;)
Sure, but it will not happen unless all hosters start acting up at the same time.
Best regards.
On Mon, 14 Jun 2010 17:47:57 +1000 Lex Trotman elextr@gmail.com wrote:
On 14 June 2010 15:41, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 14.06.2010 03:58, schrieb Lex Trotman:
I guess we should also consider that no matter how easy we think it will be there will probably be some disruption during the changeover so it should be now (immediately after a release) or not until the next release, which I think is probably better so that the hosting and workflow issues can be worked through some more. Jiri, hold that Gitorious project to keep out cyber squatters.
0.19 is just out, why wait for the next release? 0.19 is so recent, waiting for the next release will have no advantage (because we are in the same situation then as today). Can you elaborate that please?
Hi Thomas,
Sure, multi part answer.
- Yes you are right, it doesn't have to be *immediately* after a
release, just before the heavy activity approaching a release.
- What might be better if there is some delay?
Because I don't think we have got a good handle on host, bug tracker etc. The responses were far from unanimous for a switch to Git, though no one was heavily against it.
As far as I can tell Jiri is the only one who has responded who has actual experience running a Git project and that is only on Gitoroius. So I'd ask:
- Does anyone else run a Git project, which host and whats the
experience?
I run a git project on github.com and gitorious.org, but since it's a single-man project that isn't ready for public consumption, it's just a backup of my git repository in the event that all my local copies of my git repository disappear at the same time.
I have push access to http://gitorious.org/banshee-community-extensions and I have nothing bad to say about it. I don't use the web interface much, honestly speaking, except for linking the commit hash of a certain bugfix to a bug report. I just mostly fetch, pull, and push.
I think something that might be worth noting is that we should pick a host that has support http:// fetching, and even better, smart http://.
- How many people contribute to one, and what hosting service do they
use and what is the experience, is performance consistent and better than Sourceforge SVN, all around the world?
In Singapore and Malaysia, gitorious.org and github.com have been extremely stable and fast, unlike sourceforge.net.
- And does anyone have experience using any other DVCS and hosting
service that would make them recommend it, or recommend against it?
I've used bzr before, But I would recommend against it, as bzr still seems to have the occasional repository format migration which, if things go wrong, can cause your repositories to suddenly become unmergeable. Also, it's one branch per repository, which leads to as many copies of the project as you have branches (i.e. not so cheap branching).
- should the bug tracker be moved? Can it be done without losing
anything?
I'm against any bug tracker that lacks either a read/writeable web interface or a read/writeable e-mail interface. (I like launchpad.net's bug tracker, but that's just me.)
There are rather a lot of options listed here: https://git.wiki.kernel.org/index.php/GitHosting Has anyone used any?
The important things we need to know about a hosting service are:
- likely stability, some have gone offline during the GFC, but this is
hard to judge
- performance for a good range of users in a good range of locations
- reliability, low downtime
- features, hosting clones, bug tracking ?????
My answer is that I only run Git locally, so I cannot add any information.
Who can? I'm happy to collate the replies.
So far, Jiri I take it you are happy with Gitorious, it has the features, but some don't like its style, does anyone have performance problems with it? Whats its reliability like?
For Github, some really don't like its style :-)
I don't really care about whichever hosting service we use, as long as it has: * A good and stable internet connection to various places around the world (I particularly care about Malaysia and Singapore). * A fairly usable web interface that supports showing logs, browsing the tree, showing diffs for commits. (github.com and gitorious.org satisfy me in this aspect). * git:// read-only access, git+ssh:// push access, http:// read-only access. http:// push access would be a plus, though.
P.S. What's GFC?
I think something that might be worth noting is that we should pick a host that has support http:// fetching, and even better, smart http://.
Good point
- How many people contribute to one, and what hosting service do they
use and what is the experience, is performance consistent and better than Sourceforge SVN, all around the world?
In Singapore and Malaysia, gitorious.org and github.com have been extremely stable and fast, unlike sourceforge.net.
- And does anyone have experience using any other DVCS and hosting
service that would make them recommend it, or recommend against it?
I've used bzr before, But I would recommend against it, as bzr still seems to have the occasional repository format migration which, if things go wrong, can cause your repositories to suddenly become unmergeable. Also, it's one branch per repository, which leads to as many copies of the project as you have branches (i.e. not so cheap branching).
- should the bug tracker be moved? Can it be done without losing
anything?
I'm against any bug tracker that lacks either a read/writeable web interface or a read/writeable e-mail interface. (I like launchpad.net's bug tracker, but that's just me.)
There are rather a lot of options listed here: https://git.wiki.kernel.org/index.php/GitHosting Has anyone used any?
The important things we need to know about a hosting service are:
- likely stability, some have gone offline during the GFC, but this is
hard to judge
- performance for a good range of users in a good range of locations
- reliability, low downtime
- features, hosting clones, bug tracking ?????
My answer is that I only run Git locally, so I cannot add any information.
Who can? I'm happy to collate the replies.
So far, Jiri I take it you are happy with Gitorious, it has the features, but some don't like its style, does anyone have performance problems with it? Whats its reliability like?
For Github, some really don't like its style :-)
I don't really care about whichever hosting service we use, as long as it has: * A good and stable internet connection to various places around the world (I particularly care about Malaysia and Singapore). * A fairly usable web interface that supports showing logs, browsing the tree, showing diffs for commits. (github.com and gitorious.org satisfy me in this aspect). * git:// read-only access, git+ssh:// push access, http:// read-only access. http:// push access would be a plus, though.
P.S. What's GFC?
Oops sorry, non-computer acronym, global financial crisis
-- Kind regards, Chow Loong Jin
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
I believe I have some relevant info about github. I have a repository at github. http://www.github.com/danmar/cppcheck I used sourceforge+svn when I started cppcheck. But then I moved the code repository to github.
For the code hosting I think github is really good. The code review features are really useful. It is simple to make forks. The biggest disadvantages with github is that its bug tracker is not good enough and there is no release management.
- How many people contribute to one, and what hosting service do they
use and what is the experience, is performance consistent and better than Sourceforge SVN, all around the world?
30 people have contributed to cppcheck according to ohloh. Most of those contributors only provide a few patches and nothing more.
I would say that github has consistently better performance than sourceforge. Not just the repository but also the webpages. It has happened that github has been down but in my feeling it has just been temporary technical problems.
Best regards, Daniel
On Mon, Jun 14, 2010 at 09:47, Lex Trotman elextr@gmail.com wrote:
On 14 June 2010 15:41, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 14.06.2010 03:58, schrieb Lex Trotman:
I guess we should also consider that no matter how easy we think it will be there will probably be some disruption during the changeover so it should be now (immediately after a release) or not until the next release, which I think is probably better so that the hosting and workflow issues can be worked through some more. Jiri, hold that Gitorious project to keep out cyber squatters.
0.19 is just out, why wait for the next release? 0.19 is so recent, waiting for the next release will have no advantage (because we are in the same situation then as today). Can you elaborate that please?
Hi Thomas,
Sure, multi part answer.
- Yes you are right, it doesn't have to be *immediately* after a
release, just before the heavy activity approaching a release.
- What might be better if there is some delay?
Because I don't think we have got a good handle on host, bug tracker etc. The responses were far from unanimous for a switch to Git, though no one was heavily against it.
As far as I can tell Jiri is the only one who has responded who has actual experience running a Git project and that is only on Gitoroius. So I'd ask:
- Does anyone else run a Git project, which host and whats the experience?
- How many people contribute to one, and what hosting service do they
use and what is the experience, is performance consistent and better than Sourceforge SVN, all around the world?
- And does anyone have experience using any other DVCS and hosting
service that would make them recommend it, or recommend against it?
- should the bug tracker be moved? Can it be done without losing anything?
There are rather a lot of options listed here: https://git.wiki.kernel.org/index.php/GitHosting Has anyone used any?
The important things we need to know about a hosting service are:
- likely stability, some have gone offline during the GFC, but this is
hard to judge
- performance for a good range of users in a good range of locations
- reliability, low downtime
- features, hosting clones, bug tracking ?????
In fact, it is a much less critical decision which host to chose than it may seem. After creating the repository, the main developers don't have to visit the web pages of the host any more. The only thing they have to do is to push the changes to all the git hosts geany will use (it could be sourceforge, github and gitorious in parallel - it will be up to the contributors which one they'll chose [probably github or gitorious because these can host their own clones]). This can even be automated if the push is made on your own server and then propagated by some script to all the mirrors. The web pages of the host will be visited only by the contributors who want to create their own clone (and from this point they can also forget about the web interface). There are features like "merge request" at gitorious that notify the maintainter about the merge from a contributor, but this can be disabled so the only way the contributor will ask for merging his work will be through the mailing list and publishing url of his repository (wherever it is located).
Git is a distributed VCS - it doesn't matter where the user pulls from - whether it's some host like gitorious, the official repository, or a local clone on your machine - the mirrors should just be kept up to date. And for instance if github is not officially supported and there is some github lover, nobody prevents him from pulling from the official repository and pushing to a github clone so he keeps it more or less up to date (I did the same with the current geany gitorious repository [I just don't keep it up to date, but I could of course] - there will be no difference for people if they pull from there or your official git mirror). And if you dislike one host and want to move to another one, you'll just move the repository there - all the user's local clones will be still valid, they'll just have to start pulling from a different url.
So the question should rather be WHETHER to move and not WHERE to move - the latter is much less important at this point. The only thing I'd like to see is that one of the repositories makes it possible to create personal clones for external developers.
Cheers,
Jiri
In fact, it is a much less critical decision which host to chose than it may seem. After creating the repository, the main developers don't have to visit the web pages of the host any more. The only thing they have to do is to push the changes to all the git hosts geany will use (it could be sourceforge, github and gitorious in parallel - it will be up to the contributors which one they'll chose [probably github or gitorious because these can host their own clones]).
Can they create a local clone of a repo on some other server, without having to create a project? That would be good!!
This can even be
automated if the push is made on your own server and then propagated by some script to all the mirrors. The web pages of the host will be visited only by the contributors who want to create their own clone (and from this point they can also forget about the web interface). There are features like "merge request" at gitorious that notify the maintainter about the merge from a contributor, but this can be disabled so the only way the contributor will ask for merging his work will be through the mailing list and publishing url of his repository (wherever it is located).
Thats closer to the current way of working and is better IMO for pathes that are more than one-liners, some explanation of what the change is and what it does is useful.
Git is a distributed VCS - it doesn't matter where the user pulls from
- whether it's some host like gitorious, the official repository, or a
local clone on your machine - the mirrors should just be kept up to date. And for instance if github is not officially supported and there is some github lover, nobody prevents him from pulling from the official repository and pushing to a github clone so he keeps it more or less up to date (I did the same with the current geany gitorious repository [I just don't keep it up to date, but I could of course] - there will be no difference for people if they pull from there or your official git mirror). And if you dislike one host and want to move to another one, you'll just move the repository there - all the user's local clones will be still valid, they'll just have to start pulling from a different url.
Which confuses everyone, so it shouldn't happen too often.
So the question should rather be WHETHER to move and not WHERE to move
- the latter is much less important at this point. The only thing I'd
like to see is that one of the repositories makes it possible to create personal clones for external developers.
Agree
Cheers Lex
Cheers,
Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 14 Jun 2010 15:15:03 +0200 Jiří Techet techet@gmail.com wrote:
So the question should rather be WHETHER to move and not WHERE to move
- the latter is much less important at this point. The only thing I'd
like to see is that one of the repositories makes it possible to create personal clones for external developers.
I dislike to more at the moment, even I see there is a number of votes for git etc. However, I suggest this: Why not keeping one of the git mirrors up to date and build it up to some kind of official mirror with a maintainer (or a group of), who is pulling from possibles clones etc and pushing the patches well formated and revisited to geany-devel mailing list so it can be inlcduied to subversion main tree. This would be similar to subsystem maintainer inside Kernel-development-process. Quiet important here is that we need to avoid too many branches existing without sending patches upstream. However, If this is working well, we could think about later really to switch.
What do you think about?
Cheers, Frank
Sorry for any noise this post might add! Long response follows.
TL;DR: Use Gitorious and Trac.
On 06/14/2010 12:47 AM, Lex Trotman wrote:
As far as I can tell Jiri is the only one who has responded who has actual experience running a Git project and that is only on Gitoroius. So I'd ask:
- Does anyone else run a Git project, which host and whats the experience?
- How many people contribute to one, and what hosting service do they
use and what is the experience, is performance consistent and better than Sourceforge SVN, all around the world?
- And does anyone have experience using any other DVCS and hosting
service that would make them recommend it, or recommend against it?
- should the bug tracker be moved? Can it be done without losing anything?
I have experience with Mercurial (I manage a public repo containing several of my personal projects, and also a private repo for internal projects at work.) And while the hosting is all 'self-contained' (e.g. the public repo is hosted directly out of Apache with hgweb.cgi, and the private repo is the built-in hgweb daemon) I've grown to love the minimalism of Mercurial's gitweb style.
I've also recently launched a new project on GoogleCode's hosting platform. I cannot yet comment on how well their service works. It seems it's not possible to simply clone hosted repos like with gitorious, for example.
There are rather a lot of options listed here: https://git.wiki.kernel.org/index.php/GitHosting Has anyone used any?
The important things we need to know about a hosting service are:
- likely stability, some have gone offline during the GFC, but this is
hard to judge
- performance for a good range of users in a good range of locations
- reliability, low downtime
- features, hosting clones, bug tracking ?????
In that list, I've heard of only a few of them. I would suggest avoiding github (total personal opinion, here; awful web interface, and the "network graph visualizer" requires Flash, which is purely ridiculous). Both Gitorious and Savannah look great.
Gitorious maintains a fairly barebones service for git hosting, and its web interface looks ok. Its shortcoming is that it doesn't integrate a tracker, so it can be difficult to link bugs with their relevant revisions in the repo (of course, you can always do that 'by hand' like you are now, but then that's one advantage of project hosting that you're missing out on!)
Savannah's main interface is really weird, but they do offer *gitweb[2] directly! It also includes issue trackers, mailing lists, and other features that you can ignore if you don't need them. I'm not sure how well these features integrate with each other.
It's worth noting that I don't have any actual experience with any of these services. This is just from research I've done in the past while evaluating potential VCSs/hosting services. (I ended up with Mercurial, and GoogleCode.)
That said, I only want to pose the following suggestion: Pick a hosting service that encourages development. After revisiting some of these services, that only seems to be Gitorious. That "clone repository" button is just too good to pass up, and the "merge requests" feature should come in handy, as well.
After a hosting service is settled on, you'll also wanta better issue tracker. (I hate the SourceForge tracker.) My suggestion here is Trac[2] with GitPlugin. If it's possible to host Trac on geany.org, you'll be set; Trac includes a "sourceforge2trac.py" script to import the tickets from SF.
It seems reasonable to offer the source on a hosting platform like Gitorious, and hosting your own tracker that integrates with it directly.
* However, gitweb does pose some troubles when it does its "generating..." spin for a few seconds before giving the information asked for. Pretty typical when browsing the web interface between commit logs and patches.
[1] http://git.savannah.gnu.org/gitweb/ [2] http://trac.edgewall.org/
On Sun, 13 Jun 2010 23:47:37 +0200, Jiří Techet techet@gmail.com wrote:
On Sun, Jun 13, 2010 at 17:38, Chow Loong Jin hyperair@gmail.com wrote:
Bandwidth issues. If your connection to your git host sucks (sourceforge.net particularly sucks from Asian countries) then you want
Sourceforge tends to have "bad days" here too (Czech Republic) - I suspect it's a global problem.
Yepp, its well known that sf is not always the fastest plattform. Unfortunately.
Cheers, Frank
Am 12.06.2010 21:30, schrieb Jiří Techet:
Well, I have no experience with repo.or.cz, but my feeling is that this is just a "classical" type of hosting where contributors cannot easily create their own clones and have them hosted. Myself I'm a hater of anything that has "social" in its title and all the chatting nonsense (facebook, skype, ICQ to name some), but gitorious and github are much more "useful" than "social".
github is quite "social", but gitorious seems nice actually.
repo.or.cz has the bare minimum, it's just meant for hosting (and thus doesn't offer a tracker of some sort). But cloning is dead simple. You click on fork, and after a few seconds you'll see the forked repo it has created for you (so you can clone it), which is automatically hosted by repo.or.cz as a child project.
Maybe it would be a good idea to find some hosting which also has a bug tracker, otherwise it would seem strange to stick to sourceforge for bugs but XY.com for the code hosting. Has anyone tried the sourceforge git hosting?
Best regards.
On Sun, 13 Jun 2010 06:50:57 +0200, Thomas wrote:
Maybe it would be a good idea to find some hosting which also has a bug tracker, otherwise it would seem strange to stick to sourceforge for bugs but XY.com for the code hosting. Has anyone tried the sourceforge git hosting?
Ah, that raises the topic of using other bug tracking tools than Sourceforge's one :). We discussed this somewhere in the past already, to make it short: Sourceforge's bug tracker isn't that intuitive nor fast nor ideal. But it has the big advantage people don't need to register to file bug reports while it is still mostly spam-free (no idea why but it's nice). I didn't see any alternative so far while I'd like to switch to bugzilla actually. But well, there are more important problems out there.
Regards, Enrico
On Sat, 12 Jun 2010 21:30:24 +0200, Jiří wrote:
This choice will also influence the workflow in which you will use git. If contributors cannot have their branches hosted easily, then the the Linus model (one pusher pulling from contributors) will be harder to realize.
I doubt we want that. Who should be "our Linus"? I can't do that and I guess Nick also not. And I also don't see any advantage for Geany with such a scenario.
I'd rather keep the existing way of committing: a couple of people have write access to trunk (or then master). They commit their changes and patches and whatever.
Regards, Enrico
On Sun, 13 Jun 2010 13:11:43 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Sat, 12 Jun 2010 21:30:24 +0200, Jiří wrote:
This choice will also influence the workflow in which you will use git. If contributors cannot have their branches hosted easily, then the the Linus model (one pusher pulling from contributors) will be harder to realize.
I doubt we want that. Who should be "our Linus"? I can't do that and I guess Nick also not. And I also don't see any advantage for Geany with such a scenario.
I'd rather keep the existing way of committing: a couple of people have write access to trunk (or then master). They commit their changes and patches and whatever.
Regards, Enrico
Then let's not go the Linus route. We can always adopt a working model as follows, which I've attempted to translate from the svn workflow as best as I can:
We host Geany (git) on sourceforge.net. Developers who have push access (i.e. the ones who currently have commit access to svn) can push new commits there.
Contributors:- 1. Clone the git repository from sourceforge.net 2. Do their work locally, and produce commits of the fixes/new features they implement. 3. They then submit these back to you via: * Mailing list: git format-patch can generate patches formatted properly for this purpose. * Remotely hosted branches: gitorious.org/github.com can be very useful for these, no matter how much you hate them. It'd be worth having a mirror of Geany on gitorious.org/github.com to allow for users to perform remote-cloning and pushing of new commits, so that you can either rebase or merge these back into the main tree hosted at sourceforge.net.
Access control, directly translated from svn: * Anyone who can commit to svn can push to git. * Anyone who can commit to svn can create and modify branches in svn, so let anyone who can push to git create and commit to branches.
For purposes of migration to git, I think we can just adopt the model I've proposed above first, and think about any other changes to further reap any benefits git can bring later on.
Am 13.06.2010 17:59, schrieb Chow Loong Jin:
Then let's not go the Linus route. We can always adopt a working model as follows, which I've attempted to translate from the svn workflow as best as I can:
We host Geany (git) on sourceforge.net. Developers who have push access (i.e. the ones who currently have commit access to svn) can push new commits there.
Contributors:-
- Clone the git repository from sourceforge.net
- Do their work locally, and produce commits of the fixes/new features they implement.
- They then submit these back to you via:
- Mailing list: git format-patch can generate patches formatted properly for this purpose.
- Remotely hosted branches: gitorious.org/github.com can be very useful for these, no matter how much you hate them. It'd be worth having a mirror of Geany on gitorious.org/github.com to allow for users to perform remote-cloning and pushing of new commits, so that you can either rebase or merge these back into the main tree hosted at sourceforge.net.
Access control, directly translated from svn:
- Anyone who can commit to svn can push to git.
- Anyone who can commit to svn can create and modify branches in svn, so let anyone who can push to git create and commit to branches.
For purposes of migration to git, I think we can just adopt the model I've proposed above first, and think about any other changes to further reap any benefits git can bring later on.
Sounds great to me! :)
On Sun, Jun 13, 2010 at 17:59, Chow Loong Jin hyperair@gmail.com wrote:
On Sun, 13 Jun 2010 13:11:43 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Sat, 12 Jun 2010 21:30:24 +0200, Jiří wrote:
This choice will also influence the workflow in which you will use git. If contributors cannot have their branches hosted easily, then the the Linus model (one pusher pulling from contributors) will be harder to realize.
I doubt we want that. Who should be "our Linus"? I can't do that and I guess Nick also not. And I also don't see any advantage for Geany with such a scenario.
I'd rather keep the existing way of committing: a couple of people have write access to trunk (or then master). They commit their changes and patches and whatever.
Regards, Enrico
Then let's not go the Linus route. We can always adopt a working model as follows, which I've attempted to translate from the svn workflow as best as I can:
Who says that there has to be just one Linus? There can be more Linus' for geany. The main point is that for a new contributor that starts contributing often there doesn't have to be push access to the repository - just one of the Linus' pulls the changes and pushes them.
We host Geany (git) on sourceforge.net. Developers who have push access (i.e. the ones who currently have commit access to svn) can push new commits there.
Contributors:-
- Clone the git repository from sourceforge.net
- Do their work locally, and produce commits of the fixes/new features
they implement. 3. They then submit these back to you via: * Mailing list: git format-patch can generate patches formatted properly for this purpose. * Remotely hosted branches: gitorious.org/github.com can be very useful for these, no matter how much you hate them. It'd be worth having a mirror of Geany on gitorious.org/github.com to allow for users to perform remote-cloning and pushing of new commits, so that you can either rebase or merge these back into the main tree hosted at sourceforge.net.
This is exactly the way we use git for libchamplain (http://projects.gnome.org/libchamplain/): * there's the official repository at gnome (git://git.gnome.org/libchamplain) - in your case it will be sourceforge * there's a convenience mirror for contributors at gitorious (http://gitorious.org/libchamplain)
By the way, I created a geany project at gitorious when submitting my original patches:
Don't worry, I'll give up the rights for it if you decide for gitorious as a convenience repository for geany ;-).
Jiri
On Sun, 13 Jun 2010 23:59:11 +0800 Chow Loong Jin hyperair@gmail.com wrote:
On Sun, 13 Jun 2010 13:11:43 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Sat, 12 Jun 2010 21:30:24 +0200, Jiří wrote:
This choice will also influence the workflow in which you will use git. If contributors cannot have their branches hosted easily, then the the Linus model (one pusher pulling from contributors) will be harder to realize.
I doubt we want that. Who should be "our Linus"? I can't do that and I guess Nick also not. And I also don't see any advantage for Geany with such a scenario.
I'd rather keep the existing way of committing: a couple of people have write access to trunk (or then master). They commit their changes and patches and whatever.
Regards, Enrico
Then let's not go the Linus route. We can always adopt a working model as follows, which I've attempted to translate from the svn workflow as best as I can:
We host Geany (git) on sourceforge.net. Developers who have push access (i.e. the ones who currently have commit access to svn) can push new commits there.
Contributors:-
- Clone the git repository from sourceforge.net
- Do their work locally, and produce commits of the fixes/new
features they implement. 3. They then submit these back to you via:
- Mailing list: git format-patch can generate patches formatted properly for this purpose.
- Remotely hosted branches: gitorious.org/github.com can be very useful for these, no matter how much you hate them. It'd be worth having a mirror of Geany on gitorious.org/github.com to allow for users to perform remote-cloning and pushing of new commits, so that you can either rebase or merge these back into the main tree hosted at sourceforge.net.
This is correct, but I don't see any advantage of using git/bzr, mercural, bitkeeper or whatever in favor of subversion of doing this.
Thanks, Frank
On Saturday 19,June,2010 11:22 PM, Frank Lanitz wrote:
On Sun, 13 Jun 2010 23:59:11 +0800 Chow Loong Jin hyperair@gmail.com wrote:
On Sun, 13 Jun 2010 13:11:43 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Sat, 12 Jun 2010 21:30:24 +0200, Jiří wrote:
This choice will also influence the workflow in which you will use git. If contributors cannot have their branches hosted easily, then the the Linus model (one pusher pulling from contributors) will be harder to realize.
I doubt we want that. Who should be "our Linus"? I can't do that and I guess Nick also not. And I also don't see any advantage for Geany with such a scenario.
I'd rather keep the existing way of committing: a couple of people have write access to trunk (or then master). They commit their changes and patches and whatever.
Regards, Enrico
Then let's not go the Linus route. We can always adopt a working model as follows, which I've attempted to translate from the svn workflow as best as I can:
We host Geany (git) on sourceforge.net. Developers who have push access (i.e. the ones who currently have commit access to svn) can push new commits there.
Contributors:-
- Clone the git repository from sourceforge.net
- Do their work locally, and produce commits of the fixes/new
features they implement. 3. They then submit these back to you via:
- Mailing list: git format-patch can generate patches formatted properly for this purpose.
- Remotely hosted branches: gitorious.org/github.com can be very useful for these, no matter how much you hate them. It'd be worth having a mirror of Geany on gitorious.org/github.com to allow for users to perform remote-cloning and pushing of new commits, so that you can either rebase or merge these back into the main tree hosted at sourceforge.net.
This is correct, but I don't see any advantage of using git/bzr, mercural, bitkeeper or whatever in favor of subversion of doing this.
Point #2 isn't really feasible with svn, for more than one patch at a time. And then these patches can get outdated and fail to apply, requiring the person who wrote the patch to keep maintaining it until the patch is committed.
git format-patch is the solution to the aforementioned problems, since it can generate a series of patches, each with a suitable commit message, from a series of commits since the patches have some hashes included within them so that git can fall back on a 3-way merge when applying these patches if all else fails.
Of course, git format-patch can be done with geany still using git-svn, but how many developers do you want to see using git-svn before switching from svn to git? I think most of us already do, in geany's case. Hence, this discussion.
Am 19.06.2010 18:22, schrieb Chow Loong Jin:
On Saturday 19,June,2010 11:22 PM, Frank Lanitz wrote:
On Sun, 13 Jun 2010 23:59:11 +0800 Chow Loong Jinhyperair@gmail.com wrote:
On Sun, 13 Jun 2010 13:11:43 +0200 Enrico Trögerenrico.troeger@uvena.de wrote:
On Sat, 12 Jun 2010 21:30:24 +0200, Jiří wrote:
This choice will also influence the workflow in which you will use git. If contributors cannot have their branches hosted easily, then the the Linus model (one pusher pulling from contributors) will be harder to realize.
I doubt we want that. Who should be "our Linus"? I can't do that and I guess Nick also not. And I also don't see any advantage for Geany with such a scenario.
I'd rather keep the existing way of committing: a couple of people have write access to trunk (or then master). They commit their changes and patches and whatever.
Regards, Enrico
Then let's not go the Linus route. We can always adopt a working model as follows, which I've attempted to translate from the svn workflow as best as I can:
We host Geany (git) on sourceforge.net. Developers who have push access (i.e. the ones who currently have commit access to svn) can push new commits there.
Contributors:-
- Clone the git repository from sourceforge.net
- Do their work locally, and produce commits of the fixes/new
features they implement. 3. They then submit these back to you via: * Mailing list: git format-patch can generate patches formatted properly for this purpose. * Remotely hosted branches: gitorious.org/github.com can be very useful for these, no matter how much you hate them. It'd be worth having a mirror of Geany on gitorious.org/github.com to allow for users to perform remote-cloning and pushing of new commits, so that you can either rebase or merge these back into the main tree hosted at sourceforge.net.
This is correct, but I don't see any advantage of using git/bzr, mercural, bitkeeper or whatever in favor of subversion of doing this.
Point #2 isn't really feasible with svn, for more than one patch at a time. And then these patches can get outdated and fail to apply, requiring the person who wrote the patch to keep maintaining it until the patch is committed.
The main flaw of SVN IMO. It basically forces you to have multiple checkouts, each having the double size of the source code.
Of course, git format-patch can be done with geany still using git-svn, but how many developers do you want to see using git-svn before switching from svn to git? I think most of us already do, in geany's case. Hence, this discussion.
Yes, that's the point. Many of us mess with git-svn (an additional hurdle) while we could simply switch to git and make it easier for most people.
Best regards.
On Sun, 13 Jun 2010 13:11:43 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Sat, 12 Jun 2010 21:30:24 +0200, Jiří wrote:
This choice will also influence the workflow in which you will use git. If contributors cannot have their branches hosted easily, then the the Linus model (one pusher pulling from contributors) will be harder to realize.
I doubt we want that. Who should be "our Linus"? I can't do that and I guess Nick also not. And I also don't see any advantage for Geany with such a scenario.
I'd rather keep the existing way of committing: a couple of people have write access to trunk (or then master). They commit their changes and patches and whatever.
I agree.
Cheers, Frank