Le 19/08/2011 23:11, Frank Lanitz a écrit :

On Fri, 19 Aug 2011 08:57:36 -0500 Josh joshua.rh@comcast.net wrote:

...

@Lex: That makes sense. After this weekend I'll still have time, but it'll be more sparse. I'd like to be a part of it; so let me know what we/I need to do to get this going. Thanks!

1st step: We need to check for points the new system needs to offer (just because github is cool at the moment, I would have a bad feeling if we don't think about what we need before doing anything) and which system might could solve them. There is at least github, gitourios and google code if we just have a view onto git.

If we just want a Git repo, even SF.net can provide it. And if Allura happens to be available at a time (waiting forward to see what it can give, but don't seem to be for tomorrow :() it might provide some people are searching for: personal clones, pull requests, BTS integration, etc.

There are also a couple of services offering hg or bzr which are pretty similar to git.

Without knowing these two DVCS correctly, I'm not fond of switching to something else than Git -- even though they are probably both "better" than SVN. I never saw any valuable argumentation why Mercurial was a better alternative than Git, and even less for Bazaar.

So pretty much I'm looking for a specification sheet with possible matches for solution. I suggest to collect this inside the wiki.

2nd step: Decide which system fits best (doodle maybe)

3rd step: Collect what needs to be done in terms of transition. Maybe you can use the wiki for.

4th step: Setting up plan.

+1

Cheers, Colomban

On Fri, 19 Aug 2011 15:08:16 -0700 Matthew Brush mbrush@codebrainz.ca wrote:

On 08/19/2011 02:11 PM, Frank Lanitz wrote:

...

On Fri, 19 Aug 2011 08:57:36 -0500 Joshjoshua.rh@comcast.net wrote:

...

@Lex: That makes sense. After this weekend I'll still have time, but it'll be more sparse. I'd like to be a part of it; so let me know what we/I need to do to get this going. Thanks!

1st step: We need to check for points the new system needs to offer (just because github is cool at the moment, I would have a bad feeling if we don't think about what we need before doing anything) and which system might could solve them.

According to the long drawn-out discussions we've had for some time on this topic, I felt the overwhelming opinion was to use Git for version control. As for your concerns about GitHub, it's important to remember that it's just a server to host one of the repositories. They could go offline a week after switching and we would still have all of our code and history. The main reasons people are mentioning GitHub is because it's extremely popular, developer friendly, and a lot of open source projects are hosting their code there.

...

There is at least github, gitourios and google code if we just have a

Nope, I think it's just GitHub and Gitorious if we want contributor-friendly Git project hosting. I don't think Google Projects does Git at all.

I understand this. But, and maybe I'm a bit to demanding here, I would really like to see some clean collection at which somebody really thought about this. I was seeing to many things on FLOSS and related projects, where some decision was made by some feeling from mailinglist and at the end nobody felt responsible or nobody remembering the reasons. I want to prevent this at a point where we do have a chance to.

...

view onto git. There are also a couple of services offering hg or bzr

Except most of the developers don't already know and use Mercurial or Bazaar as much Git (I think).

The basic feeling is the same in terms of commit, push and pull. They are all dvcs. ;)

...

which are pretty similar to git. So pretty much I'm looking for a specification sheet with possible matches for solution. I suggest to collect this inside the wiki.

We could do this, but it's just more "beating around the bush". We already did have long discussions about this in multiple threads and I think everyone who would like to contribute (besides yourself?), at least those who have spoken up, would prefer Git and a better project site. How much more discussion is needed?

IMO, the only remaining questions are:

1. GitHub or Gitorious or Other (maybe a poll needed?)
2. When (maybe after next release)
3. Does anyone actually like or want to keep using SVN/SourceForge/the

current development process?

I don't want to impolite so I'm just asking for two things to everybody: 1.) Who likes to take over responsibility? (yepp, I really asking for a project manager here) 2.) Can you please careful clean the facts and put them together as I suggested (was demanding ;) ) in one of my previous postings. At the end, this needs to be done anyway (and you are right. Making the long discussions on mailing list short it really was a huge pro for some git based solution and the next open question would be were to host) - but I really like to have a clean documentation of facts ;)

Cheers, Frank

P.S. And yes, I still don't see any good reasons for a change as the issues we currently are experiencing, e.g. low an resources for code review will not be solved by any VCS IMHO. I might be wrong, but these are my thoughts. It just doesn't matter how patches are coming in, we need people reviewing them and applying them to main tree. We need people taking care on special parts of Geany as the libsm stuff and other open points and we need less novelistic discussion on mailing list but good usage of wiki. But these are just my 2ct. -- Frank Lanitz frank@frank.uvena.de

Just a few thoughts :

Le 20/08/2011 01:40, Matthew Brush a écrit :

On 08/19/2011 03:28 PM, Frank Lanitz wrote:

...

[...]

P.S. And yes, I still don't see any good reasons for a change as the issues we currently are experiencing, e.g. low an resources for code review will not be solved by any VCS IMHO. I might be wrong, but these are my thoughts. It just doesn't matter how patches are coming in, we need people reviewing them and applying them to main tree. We need people taking care on special parts of Geany as the libsm stuff and other open points and we need less novelistic discussion on mailing list but good usage of wiki. But these are just my 2ct.

With the current way we do things, no one even *can* take care of special parts because only 2 or 3 people have commit access and it's a PITA to contribute by squashing all your commits into a patch and bumping the ML till one of those 2 or 3 people have time to act on it. With a more open/social-type project site, you'll get people making forks to implement a feature, then they'll make a pull request, which others will see and then they will try this feature and test it, and so on. All of this can happen without having to wait for one of the 2 or 3 committers to review and apply a patch.

This point is a bit biased IMHO. Look at e.g. the last example I've seen: the ALSA project (and AFAIK the Linux kernel has a similar workflow). They use their mailing list mostly for sending and reviewing patches, using Git integrated features like format-patch, am etc.

I never tried this workflow in a large scale, but I guess it works well.

And as you said yourself, with Git you can have your own local copies, and you can actually (even already) clone a Git repo and do your stuff in it, and push to the ML (or wherever). The only "problem" is the visibility of the clone, but that's a matter of centralization, which doesn't look that much "D"VCS-ish...

I'm not saying it's not a good idea to use social-whatever way of doing it (though I hit on "social" for this but huh), I just want to say that it's not the only way it can be done efficiently.

I think we also should all read man gitworkflows :) (I still have to do so myself...)

Cheers, Colomban

On Fri, 19 Aug 2011 16:40:21 -0700 Matthew Brush mbrush@codebrainz.ca wrote:

With the current way we do things, no one even *can* take care of special parts because only 2 or 3 people have commit access and it's a PITA to contribute by squashing all your commits into a patch and bumping the ML till one of those 2 or 3 people have time to act on it. With a more open/social-type project site, you'll get people making forks to implement a feature, then they'll make a pull request, which others will see and then they will try this feature and test it, and so on. All of this can happen without having to wait for one of the 2 or 3 committers to review and apply a patch.

I'm afraid you got me wrong. I was looking for somebody saying, I'm feeling responsible for XYZ. Adding them to commiters list on SF currently is not a big deal. Even its sometimes a pain in the ass, also branching on svn is possible and working. So I'm not talking about sending patches, but feeling responsible and taking care of which differs a lot IMHO.

Cheers, Frank

Hi All,

Some mixed comments.

@Jiri I would have thought that the process for creating the Git repo was to check the existing readonly mirror then move it to the chosen host and setup access. Or do you know of some problem with it?

@Colomban, The processes described in man gitworkflows covers a wide range of projects and would need tailoring for a Geany size project. The reference posted by Matthew looks more the right size.

@Frank, you are correct, someone who has the time available needs to step up to be the project manager & work with Enrico and Colomban during the release to understand the processes and then to ensure things like nightly builds, tarballs etc don't break when the VCS is changed.

@All, what about plugins?

Cheers Lex

On 11-08-22 10:21 PM, Lex Trotman wrote:

Hi All,

@All, what about plugins?

What about Git submodules? IIUC we could have alongside the "official" `geany` repository, a `geany-plugins` repository which is the "superproject" of all our individual plugin repositories. To quote the Git Book[1]:

"Git's submodule support allows a repository to contain, as a subdirectory, a checkout of an external project. Submodules maintain their own identity; the submodule support just stores the submodule repository location and commit ID, so other developers who clone the containing project ("superproject") can easily clone all the submodules at the same revision. Partial checkouts of the superproject are possible: you can tell Git to clone none, some or all of the submodules."

This seems like the best way, if I do indeed understand how it works. There's a tutorial for this here, that I haven't read thoroughly yet[2].

[1] http://book.git-scm.com/5_submodules.html [2] http://woss.name/2008/04/09/using-git-submodules-to-track-plugins/

Cheers, Matthew Brush

Hi Lex,

On Tue, Aug 23, 2011 at 07:21, Lex Trotman elextr@gmail.com wrote:

Hi All,

Some mixed comments.

@Jiri I would have thought that the process for creating the Git repo was to check the existing readonly mirror then move it to the chosen host and setup access.  Or do you know of some problem with it?

the disadvantage of using the current read-only mirror is the following:

1. It's not complete (just 3 years of history). Could be a problem if you want to bisect some bug which has been present for a long time. Apart from this it's just nice to see the complete history.

2. There are no tags visible.

3. There are no branches and branch merges visible.

Even though it takes some time, I think it's worth doing the initial git repository setup properly because it's very hard to modify it afterwards (all contributors would have to throw away their personal clones). I think it's nice to see the complete history so you can see when each release was made, checkout any previous commit and think of the good old times when the individual commits were made.

You can get a (one-year-old) complete SVN export of Geany from here:

https://gitorious.org/geany/complete

It's not perfect - the branches aren't "glued" to the trunk in merge points and the tags are squashed with the previous commits which I don't like but it gives you an idea how a complete Geany's history looks like.

About plugins - I'd like to see them converted to git too but for me it's much less important. Plugins are usually one-man-show and require much less cooperation than Geany itself and their authors already have SVN access.

Cheers,

Jiri

On Wed, 24 Aug 2011 23:56:52 +0200 Jiří Techet techet@gmail.com wrote:

About plugins - I'd like to see them converted to git too but for me it's much less important. Plugins are usually one-man-show and require much less cooperation than Geany itself and their authors already have SVN access.

Due the huge number of contributors at the plugins project and the, well quiet often broken build, a more decentralized process would be good for the plugins. We talked about this a couple of days ago inside IRC and we came to that point, that it would be might useful to make more usage of branches and only merge to trunk, when its apply correct and build is not broken and some other points of policy is met - Well I'm imagine a bit the Linux Kernel development model even of course the plugins are not that big - not yet ;) This could be done on svn its a bit a more complicated so maybe a git (or brz, hg) would be useful here. But this is something for post-21-plugins release.

Cheers, Frank

On Thu, 25 Aug 2011 15:51:24 +1000 Lex Trotman elextr@gmail.com wrote:

[...]

...

Due the huge number of contributors at the plugins project and the, well quiet often broken build, a more decentralized process would be good for the plugins. We talked about this a couple of days ago inside IRC and we came to that point, that it would be might useful to make more usage of branches and only merge to trunk, when its apply correct and build is not broken and some other points of policy is met - Well I'm imagine a bit the Linux Kernel development model even of course the plugins are not that big - not yet ;)

Only a minor change to your new name, Frank Linus?

...

This could be done on svn its a bit a more complicated so maybe a git (or brz, hg) would be useful here. But this is something for post-21-plugins release.

Yes, with DVCS each plugin can have its own repository and the Geany project only needs to manage the aggregated build.

Yes, this was the outcome on IRC. So once a feature is ready/bug has been fixed a pull request is send to maintainer who is including them into his/her tree. Once this has been done a snapshot of that tree will be the release.

The rule would be like the Linux one, don't break Franks tree :-)

;) Yepp.

Looks like the policy needs include 64 bit test builds (at least until the int/pointer errors go away).

I agree. I'd like to have also some tests on PPC and IA64. At least a PPC (G4 or G5 Mac) I have here (only I need is somebody who is able to set it up....)

Cheers, Frank

On 26 August 2011 10:47, Matthew Brush mbrush@codebrainz.ca wrote:

On 08/25/2011 03:27 AM, Frank Lanitz wrote:

...

On Thu, 25 Aug 2011 15:51:24 +1000 Lex Trotmanelextr@gmail.com  wrote:

...

...

Yes, with DVCS each plugin can have its own repository and the Geany project only needs to manage the aggregated build.

Yes, this was the outcome on IRC. So once a feature is ready/bug has been fixed a pull request is send to maintainer who is including them into his/her tree. Once this has been done a snapshot of that tree will be the release.

Hi Matthew,

I don't know what was said on IRC (since if you don't happen to be there at the time you can't contribute, and I am not going to search through days of c**p in the logs)

My reasoning was based on past discussions around quality control of the plugins. As noted in those discussions, plugins are more and more providing essential capability and the aggregated plugins are being released in the name of the Geany project. So the project gets the blame for plugin problems and if it delegates functionality to plugins it needs to take responsibility for their quality.

So I was basically proposing that the development of the aggregated plugins follow the method of the main Geany (iaw your post) and so the same quality criteria can be applied before changes go in the devel branch thats heading towards a release. That has added a step from the current process, but it is the same as that for the main app.

I disagree with this.  I think using a workflow more like I linked to previously where people work from feature branches, and only merge to "devel" when the feature is complete (or bug fixed, etc) would be better. I just feel like limiting access *more* than before is a step backwards for the project.

Who can do the commit to devel is a different question from the workflow. The more responsible people who can do this the better (applies to main app as well). But see comments about quality above.

IMO, it would be better to give people the benefit of the doubt, and if someone continually pushes broken builds and stuff to the "devel" branch, then revoke access and work on a pull-request system like you mentioned.

Removing a permission from an individual is a very inflammatory action, better to avoid it. The requirement is being responsible, not necessarily technically brilliant.

I do think there still is a place to have a maintainer, who will be the person who reverts changes made that break the build at will, without needing to ask other people for approval and who decides when it's necessary to revoke access.

+1 for Frank for maintainer like this :)

Ditto if he has the time and interest.

Cheers Lex

On 26 August 2011 12:49, Matthew Brush mbrush@codebrainz.ca wrote:

On 08/25/2011 07:06 PM, Lex Trotman wrote:

...

I don't know what was said on IRC (since if you don't happen to be there at the time you can't contribute, and I am not going to search through days of c**p in the logs)

Nothing noteworthy was said that Frank didn't bring to the list, unless the need for coffee and something about a Sexy Waitress is noteworthy :)

...

Removing a permission from an individual is a very inflammatory action, better to avoid it.  The requirement is being responsible, not necessarily technically brilliant.

Bah, we're (probably) all adults.

Even adults has feelings, I wouldn't be too worried about the person struck off, but someone worried about their competence could be turned off from trying by observing it happen.

P.S. You really need to install Xchat :)

Work firewall doesn't allow IRC :-(

Cheers Lex

On Thu, 25 Aug 2011 17:47:25 -0700 Matthew Brush mbrush@codebrainz.ca wrote:

On 08/25/2011 03:27 AM, Frank Lanitz wrote:

...

On Thu, 25 Aug 2011 15:51:24 +1000 Lex Trotmanelextr@gmail.com wrote:

...

...

Yes, with DVCS each plugin can have its own repository and the Geany project only needs to manage the aggregated build.

Yes, this was the outcome on IRC. So once a feature is ready/bug has been fixed a pull request is send to maintainer who is including them into his/her tree. Once this has been done a snapshot of that tree will be the release.

I disagree with this. I think using a workflow more like I linked to previously where people work from feature branches, and only merge to "devel" when the feature is complete (or bug fixed, etc) would be better. I just feel like limiting access *more* than before is a step backwards for the project.

IMO, it would be better to give people the benefit of the doubt, and if someone continually pushes broken builds and stuff to the "devel" branch, then revoke access and work on a pull-request system like you mentioned.

I do think there still is a place to have a maintainer, who will be the person who reverts changes made that break the build at will, without needing to ask other people for approval and who decides when it's necessary to revoke access.

I guess I understand your thinking behind, but to be honest I don't like the thought as it implies some kind of judge with punishment. I don't want to judge work of people as everybody is doing its best (given that I would be the one who play judge)

+1 for Frank for maintainer like this :)

Thanks ;)

On Thu, 25 Aug 2011 07:27:47 +0200 Frank Lanitz frank@frank.uvena.de wrote:

On Wed, 24 Aug 2011 23:56:52 +0200 Jiří Techet techet@gmail.com wrote:

...

About plugins - I'd like to see them converted to git too but for me it's much less important. Plugins are usually one-man-show and require much less cooperation than Geany itself and their authors already have SVN access.

Due the huge number of contributors at the plugins project and the, well quiet often broken build, a more decentralized process would be good for the plugins. [...] it would be might useful to make more usage of branches and only merge to trunk, when its apply correct and build is not broken and some other points of policy is met

Taking into account what Jiří said, perhaps the plugin developers should try to follow the policy in the first place, before commiting to svn? It's not like they are lacking hard disks and have to use a branch for storage space.

On Wed, 24 Aug 2011 23:56:52 +0200 Jiří Techet techet@gmail.com wrote:

It's not perfect - the branches aren't "glued" to the trunk in merge points and the tags are squashed with the previous commits which I don't like but it gives you an idea how a complete Geany's history looks like.

Is there a way to prevent from such things?

Cheers, Frank

On 08/24/2011 02:56 PM, Jiří Techet wrote:

Hi Lex,

On Tue, Aug 23, 2011 at 07:21, Lex Trotmanelextr@gmail.com wrote:

...

Hi All,

Some mixed comments.

@Jiri I would have thought that the process for creating the Git repo was to check the existing readonly mirror then move it to the chosen host and setup access. Or do you know of some problem with it?

the disadvantage of using the current read-only mirror is the following:

1. It's not complete (just 3 years of history). Could be a problem if

you want to bisect some bug which has been present for a long time. Apart from this it's just nice to see the complete history.

2. There are no tags visible.

3. There are no branches and branch merges visible.

Even though it takes some time, I think it's worth doing the initial git repository setup properly because it's very hard to modify it afterwards (all contributors would have to throw away their personal clones). I think it's nice to see the complete history so you can see when each release was made, checkout any previous commit and think of the good old times when the individual commits were made.

You can get a (one-year-old) complete SVN export of Geany from here:

https://gitorious.org/geany/complete

It's not perfect - the branches aren't "glued" to the trunk in merge points and the tags are squashed with the previous commits which I don't like but it gives you an idea how a complete Geany's history looks like.

We could also use the SVN import on GitHub. It's offered as an option when you create a new repository. I have no idea if it suffers from the same limitations you mentioned.

Cheers, Matthew Brush

Le 22/08/2011 00:27, Jiří Techet a écrit :

[...]

Well, in my opinion the whole topic of git transition is over-discussed.

Looks the same for me, and I didn't see much new POV or useful infos since a bunch of emails.

The reason why I haven't been very active on Geany's mailing list are exactly these endless discussions which lead nowhere. To your steps:

1 and 2: GitHub or Gitorious are the only options if you want personal repositories (which is the main reason I want the git switch). It's not a crucial decision at all which one you chose - if you pick GitHub and realize it stinks, you can always move the repository to Gitorious. The only problem is that contributors would have to move their personal clones too, but it's not a big deal.

I'd like to at least have a synchronized version on git.geany.org. Even if it wouldn't have that personal clones, it could be the main clone source or at least a backup mirror.

[...]

In my opinion, there are only 3 questions to discuss and all of them have answers by now:

1. Switch to DVCS from svn? (There have been many emails written about

advantages of DVCS over svn on this mailing list and it seems most people wish the switch)

I would appreciate the switch, but since I actually use git-svn, that would not change so much for me. So yes, it'd be good IMHO, but no, it's not an absolute need.

2. Use git, hg, or something else? (git is used by majority of

open-source projects and nobody here is really familiar with anything else, so the answer seems to be clear too)

Yes PLEASE. Git. OK, I don't really know Mercurial or Bazaar, but I also never seen any reason why I would like to use it over Git, which I know pretty well.

3. Which website to use for the repository? (I suggest GitHub for now,

and if it doesn't work well, it's no problem to change it for something else later)

I personally don't really care but take into account that maybe we don't want to move the bugs (already mentioned in a previous thread...) for now.

Also I'm not sure I like such web sites (I'm not a web-interface fan), but I can adapt myself and may even like it.

Regards, Colomban

Le 27/08/2011 20:27, Frank Lanitz a écrit :

On Sat, 27 Aug 2011 18:02:41 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:

...

Le 22/08/2011 00:27, Jiří Techet a écrit :

...

[...]

Well, in my opinion the whole topic of git transition is over-discussed.

Looks the same for me, and I didn't see much new POV or useful infos since a bunch of emails.

...

The reason why I haven't been very active on Geany's mailing list are exactly these endless discussions which lead nowhere. To your steps:

1 and 2: GitHub or Gitorious are the only options if you want personal repositories (which is the main reason I want the git switch). It's not a crucial decision at all which one you chose - if you pick GitHub and realize it stinks, you can always move the repository to Gitorious. The only problem is that contributors would have to move their personal clones too, but it's not a big deal.

I'd like to at least have a synchronized version on git.geany.org. Even if it wouldn't have that personal clones, it could be the main clone source or at least a backup mirror.

Can you provide a clone which is inclduing all point Jiri mentioned?

• Branches
• Tags
• Merges?

I only have a full git-svn --stdlayout copy, so basically "no", though "partially" is also right:

* I (can) have branches (needs to co remote/name; co -b name) * I (can) have tags (huh, they looks like branches) * I *don't* have proper merges (the history is linear) * I *don't* have proper authors

Not sure how to fix this (especially merges, I have a script for the authoring part somewhere, and I think that true branches and tags should be easily created with a tiny script) but Jiří seems to know some ways.

Cheers, Colomban

On Sat, Aug 27, 2011 at 20:50, Frank Lanitz frank@frank.uvena.de wrote:

On Sat, 27 Aug 2011 20:46:37 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:

...

Le 27/08/2011 20:27, Frank Lanitz a écrit :

...

On Sat, 27 Aug 2011 18:02:41 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:

...

Le 22/08/2011 00:27, Jiří Techet a écrit :

...

[...]

Well, in my opinion the whole topic of git transition is over-discussed.

Looks the same for me, and I didn't see much new POV or useful infos since a bunch of emails.

...

The reason why I haven't been very active on Geany's mailing list are exactly these endless discussions which lead nowhere. To your steps:

1 and 2: GitHub or Gitorious are the only options if you want personal repositories (which is the main reason I want the git switch). It's not a crucial decision at all which one you chose - if you pick GitHub and realize it stinks, you can always move the repository to Gitorious. The only problem is that contributors would have to move their personal clones too, but it's not a big deal.

I'd like to at least have a synchronized version on git.geany.org. Even if it wouldn't have that personal clones, it could be the main clone source or at least a backup mirror.

Can you provide a clone which is inclduing all point Jiri mentioned?

• Branches
• Tags
• Merges?

I only have a full git-svn --stdlayout copy, so basically "no", though "partially" is also right:

• I (can) have branches (needs to co remote/name; co -b name)
• I (can) have tags (huh, they looks like branches)
• I *don't* have proper merges (the history is linear)
• I *don't* have proper authors

Not sure how to fix this (especially merges, I have a script for the authoring part somewhere, and I think that true branches and tags should be easily created with a tiny script) but Jiří seems to know some ways.

So I suggest this: Jiri can you help to do so (or does maybe the github svn clone tools does this correct?) we surely can also offer something like that from git.geany.org. But here import is needed FMPOV.

I could, but it needs some manual work and I'd like to do it just before the switch because I'm not sure if I could easily add the commits (commits on different branches and especially merges) you do between now and the switch. I was too missing a few committer names - see the original email here

http://lists.uvena.de/geany-devel/2010-June/002672.html

which I'd need to get first before performing the conversion.

Cheers, Jiri

On Mon, 29 Aug 2011 13:17:38 +0200 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:

Am 28.08.2011 23:33, schrieb Jiří Techet:

...

On Sat, Aug 27, 2011 at 20:50, Frank Lanitzfrank@frank.uvena.de wrote:

...

So I suggest this: Jiri can you help to do so (or does maybe the github svn clone tools does this correct?) we surely can also offer something like that from git.geany.org. But here import is needed FMPOV.

I could, but it needs some manual work and I'd like to do it just before the switch because I'm not sure if I could easily add the commits (commits on different branches and especially merges) you do between now and the switch. I was too missing a few committer names

• see the original email here

http://lists.uvena.de/geany-devel/2010-June/002672.html

which I'd need to get first before performing the conversion.

I could also ask the one that successfully converted our Rockbox svn repo to git, including proper branch, tag and author conversion, to write up the steps it needed. I think it was less than a day of work for him (and the Rockbox tree and history is considerably larger and more complicated than Geany's).

Well, good idea I guess. Maybe you can get some hints from him or even him to help ;)

Cheers, Frank

Hey,

Le 31/08/2011 00:01, Jiří Techet a écrit :

On Mon, Aug 29, 2011 at 13:17, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:

...

Am 28.08.2011 23:33, schrieb Jiří Techet:

...

On Sat, Aug 27, 2011 at 20:50, Frank Lanitzfrank@frank.uvena.de wrote:

...

So I suggest this: Jiri can you help to do so (or does maybe the github svn clone tools does this correct?) we surely can also offer something like that from git.geany.org. But here import is needed FMPOV.

I could, but it needs some manual work and I'd like to do it just before the switch because I'm not sure if I could easily add the commits (commits on different branches and especially merges) you do between now and the switch. I was too missing a few committer names - see the original email here

http://lists.uvena.de/geany-devel/2010-June/002672.html

which I'd need to get first before performing the conversion.

I could also ask the one that successfully converted our Rockbox svn repo to git, including proper branch, tag and author conversion, to write up the steps it needed. I think it was less than a day of work for him (and the Rockbox tree and history is considerably larger and more complicated than Geany's).

I expect the whole conversion of Geany's vcs wouldn't take more than 4 hours. I believe I know enough to perform the complete conversion myself but of course it would be useful to know someone else's experience.

FWIW, I've played a little with git-svn, and I've got a few things working/non-working:

1) as expected, it doesn't make merges looks like merges, but as a single commit. However Thomas said on IRC that SVN didn't knew merges either, maybe it makes this impossible to track then?

2) I've got a full commiters list, hopefully OK (that's the only useful part of this email actually...):

colombanw = Colomban Wendling ban@herbesfolles.org eht16 = Enrico Tröger enrico.troeger@uvena.de (no author) = Enrico Tröger enrico.troeger@uvena.de fralan = Frank Lanitz frank@frank.uvena.de frlan = Frank Lanitz frank@frank.uvena.de kretek = Frank Lanitz frank@frank.uvena.de ntrel = Nick Treleaven nick.treleaven@btinternet.com dmaphy = Dominic Hopf dmaphy@googlemail.com statc = Eugene Arshinov earshinov@gmail.com elextr = Lex Trotman elextr@gmail.com peterscholtens = Peter Scholtens peter.scholtens@xs4all.nl clytie = Clytie Siddall clytie@riverland.net.au

Frank especially, can you confirm your 3 nicks? (although I've based the matches on SF + commits)

3) We won't probably be able to create Git tags from the SVN tags because they (at least Geany-0_18 do) don't all tag a single commit (e.g. it's a branch)

I also played with svn-all-fast-export (looks like it is svn2git), and:

1) it created a 406M (!!) export, for a 38M for git-svn

2) it seems to eat some merged branches (adds a bakcup/name@rev tags)

3) although it creates some merges, some others are still missing

4) it creates tags (although I'm not certain they all are OK, but probably)

I've uploaded my git-svn result on SF [1] if anyone want to look at it for whatever reason.

Cheers, Colomban

[1] https://sourceforge.net/u/colombanw/geany/

On 1 September 2011 02:14, Frank Lanitz frank@frank.uvena.de wrote:

Am 31.08.2011 17:21, schrieb Colomban Wendling:

...

1. as expected, it doesn't make merges looks like merges, but as a

single commit.  However Thomas said on IRC that SVN didn't knew merges either, maybe it makes this impossible to track then?

This is depending on the version of svn. IIRC > 1.6 its supported by subversion.

SVN didn't properly track merges until version 1.5, IIRC the last big merge would have been the build system and at that stage at least one of the main developers was still using 1.4 and we found it damaged the merge data, so I did the merge of build with 1.5. It may therefore be the only merge with SVN merge data depending on when the recalcitrant developer updated his SVN client.

Cheers Lex

Am 31.08.2011 17:21, schrieb Colomban Wendling:

2. I've got a full commiters list, hopefully OK (that's the only useful

part of this email actually...):

colombanw = Colomban Wendling ban@herbesfolles.org eht16 = Enrico Tröger enrico.troeger@uvena.de (no author) = Enrico Tröger enrico.troeger@uvena.de fralan = Frank Lanitz frank@frank.uvena.de frlan = Frank Lanitz frank@frank.uvena.de kretek = Frank Lanitz frank@frank.uvena.de ntrel = Nick Treleaven nick.treleaven@btinternet.com dmaphy = Dominic Hopf dmaphy@googlemail.com statc = Eugene Arshinov earshinov@gmail.com elextr = Lex Trotman elextr@gmail.com peterscholtens = Peter Scholtens peter.scholtens@xs4all.nl clytie = Clytie Siddall clytie@riverland.net.au

Frank especially, can you confirm your 3 nicks? (although I've based the matches on SF + commits)

Not sure, where fralan have been used on svn, but I can.

Cheers, Frank

Le 31/08/2011 18:18, Frank Lanitz a écrit :

Am 31.08.2011 17:21, schrieb Colomban Wendling:

...

3. We won't probably be able to create Git tags from the SVN tags

because they (at least Geany-0_18 do) don't all tag a single commit (e.g. it's a branch)

Can you go into more detail which are not working? IIRC we only had one or two of tag/branches issues within the releases.

$ git log --graph --decorate --pretty=oneline --abbrev-commit remotes/tags/Geany-0_18

* 8c84d70 (tags/Geany-0_18) Tag the 0.18 release. |\ | * d6ec2f3 Fix opening of local files in the browser on Windows. * | 6df16fe Tag the 0.18 release. |/ * cb9c34f Add missing include path to fix 'make distcheck'.

Hum, actually it looks like it's my bad since it simply looks like a re-tagging, so the forked history isn't interesting. So maybe tags aren't a problem -- which would be cool :)

Cheers, Colomban

Hi Jiri,

Great job, thanks. Its going to take a while to inspect, but a couple of comments below (I'm only looking at the final rewrite-history version).

Note I don't think we need perfection for its own sake, we need to be able to use the history to identify where regressions were introduced and fix them and to show attribution as well as SVN did. As far as I can see those requirements are met.

[...]

I used the --metadata parameter so the original SVN revision gets recorded into the git commit comment. I found this useful because some commit entries refer to SVN commit number and it wouldn't be clear which commit it was without this information. The resulting repository is here:

Sounds worthwhile.

https://gitorious.org/geany-svn2git/geany-svn2git

There are a few problems with the import. First, tags are in separate mini-branches like

http://dl.dropbox.com/u/2554438/1.png

and some (but not all) branches are not merged:

http://dl.dropbox.com/u/2554438/2.png

I tried to address these issues in the following steps.

[...]

The result looks this way:

http://dl.dropbox.com/u/2554438/3.png

Looks good.

3. I tried to add all the merges information that wasn't performed

automatically. It was quite easy - I found all commits with "merge" in their name and they usually specified what branch was merged. Then I set the parents accordingly in the grafts file:

[...]

I didn't do this for the bs2 and sm branches which IMO shouldn't be a part of geany's main repository but rather in people's personal branches.

Agree, although unless I get more time bs2 can just go away.

4. I removed all "svn" mentions from the .git directory - all the

branches were set as remote tracking branches of the svn repository but as Geany is not going to use svn any more, this is not necessary.

Yes.

5. I deleted refs to all merged branches. All the branches created

during geany's existence were present and active so "git branch" output something like this:

[...]

But many of the merged branches aren't active any more (they were created just to implement a single feature) so I removed refs to the following branches:

[...]

Agree.

6. I made some minor cleanup. There were things like this:

http://dl.dropbox.com/u/2554438/6.png http://dl.dropbox.com/u/2554438/7.png

The first is a strange mini-branch created by cvs import and as it didn't contain any useful commits, I've removed it (if the "start" tag is wanted, the "Initial revision" commit can be tagged directly). Similarly, the second seems to be a tag created by mistake so I have removed it as well.

Thats before my time, but sounds sensible.

[...]

Now it's time for your comments - please have a look at the repository and tell me what more needs to be changed (especially check all the branches and merges, I'm not very much familiar with geany's history). I have a few comments (and questions) myself:

The bits I'm familiar with look right enough to be usable.

1. Some branch names should be renamed (e.g. Geany-0_19_1) because

they have the same name as tags and they are ambiguous when doing "git checkout". Some naming scheme for stable branches should be invented.

I notice there is some inconsistency in naming recent branches whilst naming for tags is consistent. In olden times branches were named like Geany-0.10.2 but only lately has it changed to underscores. Tags always used underscores. So maybe go back to using dots in branch names (and rename clashing ones).

2. There are some strange places in the history like this:

http://dl.dropbox.com/u/2554438/8.png

The commit says "create branch" but it appears the branch is actually merged. Moreover, the merged branch appears not to contain any commit. There are more examples like this in the history. Any idea what may have caused this? Should the empty branches be deleted from the history or kept as they are?

This looks like attachment to me (sorry for the attachment, firewall prevents uploading to most sharing sites)

It appears at the start of the branch which is right, how are you viewing it?

3. I haven't found a merge point for the "dynamic-editor-menu" branch.

Has it been merged to trunk?

4. The "unstable" branch is a bit specific in that it has been

created/merged/removed several times. The svn import however doesn't reflect the branch's removal after merge so in the history it appears to be continuous (and then there are commits like "create unstable branch" even though the branch already exists). I don't know the history well enough to be sure when the branch can be deleted so I left it continuous. I think it doesn't matter much, just mentioning it for completeness.

I think it isn't going to hinder the usefulness if its continuous, and when we decide the new workflow "unstable" (or "develop" or some similar name) is likely to become continuous anyway.

5. I kept the bs2 and sm branches in the repository  but once the

migration is done, they should be cloned by their owners and should be removed from the main repository.

Agree

End of the long email finally! I tried to record all what needs to be done so nothing is forgotten once the real migration takes place because some of the stuff took some time to discover.

And again well done and thanks.

Cheers Lex

Am 06.09.2011 05:39, schrieb Lex Trotman:

I see a gentleman called Linus is doing a test of Github for us:

https://lkml.org/lkml/2011/9/4/92

;)

Am 06.09.2011 05:29, schrieb Lex Trotman:

...

1. Some branch names should be renamed (e.g. Geany-0_19_1) because

...

they have the same name as tags and they are ambiguous when doing "git checkout". Some naming scheme for stable branches should be invented.

I notice there is some inconsistency in naming recent branches whilst naming for tags is consistent. In olden times branches were named like Geany-0.10.2 but only lately has it changed to underscores. Tags always used underscores. So maybe go back to using dots in branch names (and rename clashing ones).

I agree to use a consitent way. With migration to git we could clean that also out I guess.

Cheers, Frank

Hi all,

Now the release is out, it's time for the real migration. There's things to do then, and perhaps a few we still need to agree on.

Le 05/09/2011 23:05, Jiří Techet a écrit :

[...]

End of the long email finally! I tried to record all what needs to be done so nothing is forgotten once the real migration takes place because some of the stuff took some time to discover.

@Jiří: Would you mind doing the real export since you know have a little experience?

@all: We will switch to Git, and we need to choose basically between GitHub and Gitorious. I'd vote for trying GitHub, just because it has one thing I quite liked and that Gitorious don't seem to have: comments on a particular commit's line. I did use it a few times with Matthew, and I felt it quite convenient to comment details [1] Apart that I don't mind, both have the necessary stuff, and Gitorious is more "free as in freedom".

Also, I think that we should at least try Vincent Driessen's branching model [2] (e.g. develop branch + feature branches + release branches). It might looks a bit containing at first glance, but also makes things clean -- but note I never tried it in a real project, maybe I'm wrong.

Finally, we'll need to "all" (at least committers -- Nick, Enrico, Frank and I --, Enrico and I) work a bit together to do the switch:

* committers needs to stop committing to SVN when export to Git starts * somebody (Jiří?) needs to export the SVN repo * somebody (me I think) need to setup an "upstream" repo on GitHub/Gitorious * we'll have to update everything that assume we commit to SF's SVN (some mirroring, commit ML, etc). Enrico, I guess we'll need you at least to help here still a bit, sorry ^^

So, we'll need to work together soon, and that'll need us to coordinate ourselves. So Jiří (if you accept re-exporting), Enrico, Nick and Frank: when can we do the actual switch? I can have the time whenever I want this week, I just need to know ;)

It would be good if all this could be done as soon as possible so we can start development again using this new scheme. Sooner's better.

Cheers, Colomban

[1] I don't suggest to move all discussion outside the ML, far from me this idea. [2] http://nvie.com/posts/a-successful-git-branching-model/

Le 03/10/2011 17:32, Frank Lanitz a écrit :

On Mon, 03 Oct 2011 17:28:14 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:

...

Frank: when can we do the actual switch? I can have the time whenever I want this week, I just need to know ;)

I suggest weekend around 2011-10-29. At least at this weekend I've nothing planned yet. But IIRC Enrico was on travel at this date.

I feel it a bit too far, but...

However, I think that for normal committers (you, Nick), there's not much to do:

1) stop committing to SVN during the export; 2) create an account on the new hosting site if not already done; 3) tell the repo owner (me(?)) to grant you commit & stuff rights; 4) start committing using Git on new host.

Apart 1, you can even still commit during the process since Git is a DVCS, only push would require steps 2 and 3.

I think this is pretty cheap and can probably be done in a couple of minutes, plus maybe another couple of minutes to read/check the new committing rules (e.g. push development commit to develop branch rather than master, etc.).

The big part is the SVN export/import and porting of "commit hooks", not sure if you have some?

I'm not saying you shouldn't participate (the more qualified volunteers the better!), just that maybe if you haven't the time we can do by ourselves ;)

Cheers, Colomban

Am Montag, den 03.10.2011, 17:28 +0200 schrieb Colomban Wendling:

Apart that I don't mind, both have the necessary stuff, and Gitorious is more "free as in freedom".

Exactly the reason why I'd personally prefer Gitorous over Github. :)

Regards, Dominic

On 11-10-03 08:33 AM, Dominic Hopf wrote:

Am Montag, den 03.10.2011, 17:28 +0200 schrieb Colomban Wendling:

...

Apart that I don't mind, both have the necessary stuff, and Gitorious is more "free as in freedom".

Exactly the reason why I'd personally prefer Gitorous over Github. :)

Do you plan to put a copy of Gitorious's web UI on your own server or something? Maybe installed next to your local GMail installation?

</sarcasm>

Cheers, Matthew Brush

Le 03/10/2011 17:35, Frank Lanitz a écrit :

On Mon, 03 Oct 2011 17:28:14 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:

...

@all: We will switch to Git, and we need to choose basically between GitHub and Gitorious. I'd vote for trying GitHub, just because it has one thing I quite liked and that Gitorious don't seem to have: comments on a particular commit's line. I did use it a few times with Matthew, and I felt it quite convenient to comment details [1] Apart that I don't mind, both have the necessary stuff, and Gitorious is more "free as in freedom".

I'm not very emotional here. Gitorious really looks a bit more free whereas at Github I always have the feeling they want to sell me something (ok... somehow the services needs to be paid). On the other hand the featureset around an project looks a bit better at github in my feeling. So. I don't care much and I do have an account on both :)

I basically feel exactly the same ^^ And the only feature GitHub has that I may find missing on Gitosis is the line-comments. Others like tracker, pastes, etc. don't seem to be particularly useful for us.

So maybe we should go Gitorious to feel good, and do all review using git-format-patched emails or something :)

Cheers, Colomban

On Mon, Oct 3, 2011 at 17:35, Frank Lanitz frank@frank.uvena.de wrote:

On Mon, 03 Oct 2011 17:28:14 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:

...

@all:  We will switch to Git, and we need to choose basically between GitHub and Gitorious. I'd vote for trying GitHub, just because it has one thing I quite liked and that Gitorious don't seem to have: comments on a particular commit's line.  I did use it a few times with Matthew, and I felt it quite convenient to comment details [1] Apart that I don't mind, both have the necessary stuff, and Gitorious is more "free as in freedom".

I'm not very emotional here. Gitorious really looks a bit more free whereas at Github I always have the feeling they want to sell me something (ok... somehow the services needs to be paid). On the other hand the featureset around an project looks a bit better at github in my feeling. So. I don't care much and I do have an account on both :)

While I also agree that Gitorious is more "free", at the same time I also feel the lack of resources it has. The web pages have minor bugs like overflowing text in some cases which haven't been fixed for ages. The fact that GitHub has commercial part also guarantees they get some funds to maintain the pages, servers, etc. I don't know who's behind Gitorious but someone has to pay for the servers and if the funding is gone, Gitorious could end like BerliOS.

For these reasons I'm more inclined towards GitHub. But with git it's never problem to change the hosting pages anyway.

Cheers, Jiri

On 11-10-03 05:25 PM, Lex Trotman wrote:

On 4 October 2011 03:43, Jiří Techettechet@gmail.com wrote:

...

On Mon, Oct 3, 2011 at 17:35, Frank Lanitzfrank@frank.uvena.de wrote:

...

On Mon, 03 Oct 2011 17:28:14 +0200 Colomban Wendlinglists.ban@herbesfolles.org wrote:

...

@all: We will switch to Git, and we need to choose basically between GitHub and Gitorious. I'd vote for trying GitHub, just because it has one thing I quite liked and that Gitorious don't seem to have: comments on a particular commit's line. I did use it a few times with Matthew, and I felt it quite convenient to comment details [1] Apart that I don't mind, both have the necessary stuff, and Gitorious is more "free as in freedom".

I'm not very emotional here. Gitorious really looks a bit more free whereas at Github I always have the feeling they want to sell me something (ok... somehow the services needs to be paid). On the other hand the featureset around an project looks a bit better at github in my feeling. So. I don't care much and I do have an account on both :)

While I also agree that Gitorious is more "free", at the same time I also feel the lack of resources it has. The web pages have minor bugs like overflowing text in some cases which haven't been fixed for ages. The fact that GitHub has commercial part also guarantees they get some funds to maintain the pages, servers, etc. I don't know who's behind Gitorious but someone has to pay for the servers and if the funding is gone, Gitorious could end like BerliOS.

For all these reasons I'd also suggest github, gitorious grew out of a one person project and still feels like it as Jiri said. We don't want to have to worry about the hosting service.

Also gitorious is a good bit slower in this part of the world.

See my other message too, about the email, IRC, notifications and RSS features plus the fork queue. There's also a few more things that possibly could be useful at some point in the future if Enrico ever didn't want to host them anymore; web hosting, wiki, messaging. The issue tracker is also good too, but as we've previously discussed it might not be useful to us.

I think it's cool that the software running Gitorious is FOSS, but I don't think SourceForge.net is FOSS[1] and it hosts *tons* of FOSS projects including Geany currently, not to mention Google Projects, BitBucket, and most of the other big ones. It seems silly to chose Gitorious over GitHub if this is the only advantage. I seriously doubt we'll be installing our own copy of Gitorious web UI, and the backing software, the important part, behind both is still FOSS (Git).

Cheers, Matthew Brush

[1] http://en.wikipedia.org/wiki/SourceForge_Enterprise_Edition

Le 03/10/2011 18:59, Jiří Techet a écrit :

On Mon, Oct 3, 2011 at 17:28, Colomban Wendling lists.ban@herbesfolles.org wrote:

...

Hi all,

Now the release is out, it's time for the real migration. There's things to do then, and perhaps a few we still need to agree on.

Le 05/09/2011 23:05, Jiří Techet a écrit :

...

[...]

End of the long email finally! I tried to record all what needs to be done so nothing is forgotten once the real migration takes place because some of the stuff took some time to discover.

@Jiří: Would you mind doing the real export since you know have a little experience?

Sure, no problem. Just one thing I'd like to mention - I may be a security problem. During the export I can modify any commit (e.g. to send me the contents of the editor by email) and you probably won't notice. On the other hand, the good thing is that:

Right, good remark, though making it gives you even more credit ^^

1. I don't feel it's something I'd like to do (but you cannot be sure

I'm telling you the truth)

Heh, thanks for willingness at least!

2. You can compare the current state of master with your SVN checkout

so you'll see immediately if there's something wrong with the top of trunk. I might modify some past commits but these would have lower impact because everyone either uses the latest trunk or the latest stable release.

Yeah, there are easy ways to check the result fits SVN HEAD. Checking older branches and tags are a bit harder, yet doable, but as you say yourself, it's less sensitive. And let's be honest, I could be the bad guy here too... ^^

Actually what's much more probable is that I screw up the conversion somehow ;-).

Not better than I would do ;)

...

[...]

It would be good if all this could be done as soon as possible so we can start development again using this new scheme. Sooner's better.

About the timing, I'd prefer this weekend. There have been suggestions like 2011-10-29 but this is my birthday and even though I like Geany, I want to spend my birthday in a different way than making git conversions ;-).

I can't understand this, it's soooo selfish ;( (just kidding)

Actually I feel would prefer it to be next weekend because it's sooner, and as said in another mail, I'm not sure we really need more than you, Enrico and I to complete it.

Let's wait for Enrico's answer (if he's still on that ML, hehe!) and see when he got enough spare time to spend on it.

Cheers, Colomban

On Mon, 3 Oct 2011 18:59:49 +0200 Jiří Techet techet@gmail.com wrote:

On Mon, Oct 3, 2011 at 17:28, Colomban Wendling lists.ban@herbesfolles.org wrote:

...

Hi all,

Now the release is out, it's time for the real migration.  There's things to do then, and perhaps a few we still need to agree on.

Le 05/09/2011 23:05, Jiří Techet a écrit :

...

[...]

End of the long email finally! I tried to record all what needs to be done so nothing is forgotten once the real migration takes place because some of the stuff took some time to discover.

@Jiří: Would you mind doing the real export since you know have a little experience?

Sure, no problem. Just one thing I'd like to mention - I may be a security problem. During the export I can modify any commit (e.g. to send me the contents of the editor by email) and you probably won't notice. On the other hand, the good thing is that:

1. I don't feel it's something I'd like to do (but you cannot be sure

I'm telling you the truth)

Well. We can verify the hash of source code after transition with the hash we do have signed on server or e.g. in our personal git repos.

2. You can compare the current state of master with your SVN checkout

so you'll see immediately if there's something wrong with the top of trunk. I might modify some past commits but these would have lower impact because everyone either uses the latest trunk or the latest stable release.

ACK.

About the timing, I'd prefer this weekend. There have been suggestions like 2011-10-29 but this is my birthday and even though I like Geany, I want to spend my birthday in a different way than making git conversions ;-).

I'm fine also with this.

Cheers, Frank

On Mon, 3 Oct 2011 22:18:46 +0200 Jiří Techet techet@gmail.com wrote:

On Mon, Oct 3, 2011 at 20:21, Frank Lanitz frank@frank.uvena.de wrote:

...

On Mon, 3 Oct 2011 18:59:49 +0200 Jiří Techet techet@gmail.com wrote:

...

On Mon, Oct 3, 2011 at 17:28, Colomban Wendling lists.ban@herbesfolles.org wrote:

...

Hi all,

Now the release is out, it's time for the real migration.  There's things to do then, and perhaps a few we still need to agree on.

Le 05/09/2011 23:05, Jiří Techet a écrit :

...

[...]

End of the long email finally! I tried to record all what needs to be done so nothing is forgotten once the real migration takes place because some of the stuff took some time to discover.

@Jiří: Would you mind doing the real export since you know have a little experience?

Sure, no problem. Just one thing I'd like to mention - I may be a security problem. During the export I can modify any commit (e.g. to send me the contents of the editor by email) and you probably won't notice. On the other hand, the good thing is that:

1. I don't feel it's something I'd like to do (but you cannot be

sure I'm telling you the truth)

Well. We can verify the hash of source code after transition with the hash we do have signed on server or e.g. in our personal git repos.

No, I don't think you can - if you modify a commit in the past (and this will happen because older commits have to be added), the checksums of present commits change too. I don't know how exactly git computes the checksums but it takes history into account too so nobody can insert malicious commit without being noticed. This is also why it's important to get the conversion right because later changes are very problematic (all peoples personal clones become invalid).

I didn't mean the git hash of commit or tree, but comparing the hash of the tar of the working copies of current svn head and git head after.

Cheers, Frank

Hello guys, I’m new here and I use Geany for a year now, pretty sure even more in facts.

I love Git a lot, here is my personal view so.

On 03/10/2011 23:02, Enrico Tröger wrote:

On Mon, 03 Oct 2011 17:28:14 +0200, Colomban wrote:

...

Hi all,

Now the release is out, it's time for the real migration. There's things to do then, and perhaps a few we still need to agree on.

Yay, yay, yay.

...

@all: We will switch to Git, and we need to choose basically between GitHub and Gitorious. I'd vote for trying GitHub, just because it has one thing I quite liked and that Gitorious don't seem to have: comments on a particular

While I usually plead for free software I'd also vote for Github in this regard. In the last weeks I started to use it for smaller personal stuff just to get it hosted somewhere, easily. And it worked. Github is just damn easy, fast and intuitive. While I have not much experience with Gitorious, it feels more like the opposite. Though this is just my personal opinion.

I like Github the best. It’s shiny, powerful, up-to-date, and in active development. I didn’t use Gitorious that much, but the few times I had to deal with, I didn’t like it. I can’t remind me why right now, should test again.

...

Finally, we'll need to "all" (at least committers -- Nick, Enrico, Frank and I --, Enrico and I) work a bit together to do the switch:

• committers needs to stop committing to SVN when export to Git starts
• somebody (Jiří?) needs to export the SVN repo
• somebody (me I think) need to setup an "upstream" repo on

GitHub/Gitorious

• we'll have to update everything that assume we commit to SF's SVN

(some mirroring, commit ML, etc). Enrico, I guess we'll need you at

Well, the GIT mirror at git.geany.org gets rather useless when Geany's source itself is maintained in GIT, if we want, we can keep it up running for backup or whatever purposes. I assume it's no problem to change the repository to pull from a real GIT repo instead of SVN.

The commit mails may be more complicated, at least on Github there seems nothing ready-to-use AFAIK. They have the HTTP-Push hook which seems quite appropriate. We just need a script to receive that push and make it into a mail. However, I'm optimistic there is somewhere a usable implementation out there on the net.

Github have many service hooks, some existing may be the good one. If not, I think it would be easy to add some hook and get it integrated in Github.

I'd also need to adjust the nightly builds and some update scripts on geany.org but this is less important and can be done asynchronously, read later. The only critical to me are the commit mails.

...

So, we'll need to work together soon, and that'll need us to coordinate ourselves. So Jiří (if you accept re-exporting), Enrico, Nick and Frank: when can we do the actual switch? I can have the time whenever I want this week, I just need to know ;)

I'm also for as soon as possible, upcoming weekend would be fine for me, ideally on Sunday.

Regards, Enrico

I’d love hacking Geany using Git, keep going!

Cheers,

--

Quentin "Sardem FF7" Glidic

On Mon, 03 Oct 2011 15:17:44 -0700, Matthew wrote:

On 11-10-03 02:02 PM, Enrico Tröger wrote:

...

The commit mails may be more complicated, at least on Github there seems nothing ready-to-use AFAIK. They have the HTTP-Push hook which seems quite appropriate. We just need a script to receive that push and make it into a mail. However, I'm optimistic there is somewhere a usable implementation out there on the net.

GitHub has an "Email" service hook, presumably you could get this to send a message to some mailing list. There's also a service hook for IRC.

Oops, I must have overlooked it somehow or they just added it after I checked last time :D.

Anyways, I tried setting it up and as some of you might have seen, a test commit mail gone through onto the list, so it works pretty straight and easy.

Regards, Enrico

On 11-10-05 04:23 PM, Colomban Wendling wrote:

Le 03/10/2011 23:02, Enrico Tröger a écrit :

...

While I usually plead for free software I'd also vote for Github in this regard. In the last weeks I started to use it for smaller personal stuff just to get it hosted somewhere, easily. And it worked. Github is just damn easy, fast and intuitive. While I have not much experience with Gitorious, it feels more like the opposite. Though this is just my personal opinion.

Well then, let's try GitHub. I also prefer FOSS everywhere, but GitHub

We should make a completely separate GitHub account called "geany", then convert it into an "Organization"[1], which allows all kinds of more neat features for a project like Geany (as opposed to having it as a "Personal" account). See an example FOSS project account here[2].

I will volunteer to handle setting up an "Organization" account and with the initial setup for service hooks and stuff.

Cheers, Matthew Brush

[1] https://github.com/blog/674-introducing-organizations [2] https://github.com/mongodb

On 6 October 2011 17:35, Jacques du Rand jacquesdr@gmail.com wrote:

Hi Guys

SILLY question ! and yes I know I can google but thought you guys might have a goto guide for it ??

yeah, go to google :)

"everyday git", try that and/or tutorial all on the git site :)

Cheers lex

Since Geany is going to git... and i've (please tell me I'm not the only one) have never used git (as an active developer)

everybody was a never user once

So wat in your opinion was the best intro/tutorial/manual about Git that you have read ? I.e if your mom wants to learn git where would you point her ? :) Regards Jacques

On Thu, Oct 6, 2011 at 1:43 AM, Matthew Brush mbrush@codebrainz.ca wrote:

...

On 11-10-05 04:23 PM, Colomban Wendling wrote:

...

Le 03/10/2011 23:02, Enrico Tröger a écrit :

...

While I usually plead for free software I'd also vote for Github in this regard. In the last weeks I started to use it for smaller personal stuff just to get it hosted somewhere, easily. And it worked. Github is just damn easy, fast and intuitive. While I have not much experience with Gitorious, it feels more like the opposite. Though this is just my personal opinion.

Well then, let's try GitHub.  I also prefer FOSS everywhere, but GitHub

We should make a completely separate GitHub account called "geany", then convert it into an "Organization"[1], which allows all kinds of more neat features for a project like Geany (as opposed to having it as a "Personal" account).  See an example FOSS project account here[2].

I will volunteer to handle setting up an "Organization" account and with the initial setup for service hooks and stuff.

Cheers, Matthew Brush

[1] https://github.com/blog/674-introducing-organizations [2] https://github.com/mongodb _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

---

Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Le 06/10/2011 23:01, Enrico Tröger a écrit :

On Wed, 05 Oct 2011 16:43:42 -0700, Matthew wrote:

...

On 11-10-05 04:23 PM, Colomban Wendling wrote:

...

Le 03/10/2011 23:02, Enrico Tröger a écrit :

...

While I usually plead for free software I'd also vote for Github in this regard. In the last weeks I started to use it for smaller personal stuff just to get it hosted somewhere, easily. And it worked. Github is just damn easy, fast and intuitive. While I have not much experience with Gitorious, it feels more like the opposite. Though this is just my personal opinion.

Well then, let's try GitHub. I also prefer FOSS everywhere, but GitHub

We should make a completely separate GitHub account called "geany", then convert it into an "Organization"[1], which allows all kinds of more neat features for a project like Geany (as opposed to having it as a "Personal" account). See an example FOSS project account here[2].

I will volunteer to handle setting up an "Organization" account and with the initial setup for service hooks and stuff.

Yeehaw. Er, I think this is a good idea.

Then we could also migrate the "talks" and "newsletter" repositories from git.geany.org to Github into the Geany "organisation" since these two repositories are no read-only mirror repositories and so better fit together with the rest of the project's code at one place.

And we could integrate the geany-plugins' repository there.

Good points, +1 :)

Cheers, Colomban

On Thu, Oct 6, 2011 at 01:23, Colomban Wendling lists.ban@herbesfolles.org wrote:

Le 03/10/2011 23:02, Enrico Tröger a écrit :

...

On Mon, 03 Oct 2011 17:28:14 +0200, Colomban wrote:

...

Hi all,

Now the release is out, it's time for the real migration.  There's things to do then, and perhaps a few we still need to agree on.

Yay, yay, yay.

...

@all:  We will switch to Git, and we need to choose basically between GitHub and Gitorious. I'd vote for trying GitHub, just because it has one thing I quite liked and that Gitorious don't seem to have: comments on a particular

While I usually plead for free software I'd also vote for Github in this regard. In the last weeks I started to use it for smaller personal stuff just to get it hosted somewhere, easily. And it worked. Github is just damn easy, fast and intuitive. While I have not much experience with Gitorious, it feels more like the opposite. Though this is just my personal opinion.

Well then, let's try GitHub.  I also prefer FOSS everywhere, but GitHub seems to be at least working fine, stable & stuff.  And as we don't stop to say, we can anyway switch to another host if it feels too bad at some point.  Of course keeping the same hosting is easier for people tracking the repo, but it's not really hard to change the remote either if there is a good reason to do so.

...

...

Finally, we'll need to "all" (at least committers -- Nick, Enrico, Frank and I --, Enrico and I) work a bit together to do the switch:

• committers needs to stop committing to SVN when export to Git starts
• somebody (Jiří?) needs to export the SVN repo
• somebody (me I think) need to setup an "upstream" repo on

GitHub/Gitorious

• we'll have to update everything that assume we commit to SF's SVN

(some mirroring, commit ML, etc). Enrico, I guess we'll need you at

Well, the GIT mirror at git.geany.org gets rather useless when Geany's source itself is maintained in GIT, if we want, we can keep it up running for backup or whatever purposes. I assume it's no problem to change the repository to pull from a real GIT repo instead of SVN.

I'd like to see it still up as a mirror if you don't mind (heh, it's your server after all).  This would also make us have a "stable" hosting since we could change it's origin if it actually moves.

...

The commit mails may be more complicated, at least on Github there seems nothing ready-to-use AFAIK. They have the HTTP-Push hook which seems quite appropriate. We just need a script to receive that push and make it into a mail. However, I'm optimistic there is somewhere a usable implementation out there on the net.

Matthew seems to suggest it may be easy, let's hope so :D  Maybe I/you could try with another project just to see if this work, not to rush the final day ^^

...

I'd also need to adjust the nightly builds and some update scripts on geany.org but this is less important and can be done asynchronously, read later. The only critical to me are the commit mails.

Great then, makes the plan looking even more reasonable :)

...

...

So, we'll need to work together soon, and that'll need us to coordinate ourselves.  So Jiří (if you accept re-exporting), Enrico, Nick and Frank: when can we do the actual switch?  I can have the time whenever I want this week, I just need to know ;)

I'm also for as soon as possible, upcoming weekend would be fine for me, ideally on Sunday.

OK, let's say Sunday then since it seems to fit :)

ACK. Would it be possible that I start with the conversion on Saturday evening already? First I'm not sure how much time I'll have on Sunday, second it gives us some time buffer if something goes wrong or if I need some further clarifications during the conversion. From your side it would just mean to stop comitting to SVN Saturday evening (let's say 6 P.M. CET which is GMT+2 during summer - recalculate it to your time zone).

In any case, I'll send an announcement that I started with the conversion.

Cheers, Jiri

Le 06/10/2011 22:35, Enrico Tröger a écrit :

On Thu, 6 Oct 2011 10:52:44 +0200, Jiří wrote:

...

...

OK, let's say Sunday then since it seems to fit :)

ACK. Would it be possible that I start with the conversion on Saturday evening already? First I'm not sure how much time I'll have on Sunday, second it gives us some time buffer if something goes wrong or if I

Good idea. I'd be fine with Saturday evening.

+1, and I'm fine with Saturday evening too.

...

need some further clarifications during the conversion. From your side it would just mean to stop comitting to SVN Saturday evening (let's say 6 P.M. CET which is GMT+2 during summer - recalculate it to your time zone).

In any case, I'll send an announcement that I started with the conversion.

Maybe CC Nick, I'm not sure he reads all ML's mail, and he better know it :)

Cheers, Colomban

Hi,

I'm trying to get everything ready for the conversion and there are still a few points unresolved:

I have a few comments (and questions) myself:

1. Some branch names should be renamed (e.g. Geany-0_19_1) because

they have the same name as tags and they are ambiguous when doing "git checkout". Some naming scheme for stable branches should be invented.

I was proposing to have two digit branches and three digit tags:

Geany-0_19 - maintenance branch Geany-0_19_0 - tag Geany-0_19_1 - tag Geany-0_19_2 - tag

Do you agree or do you prefer some different naming scheme?

[...]

3. I haven't found a merge point for the "dynamic-editor-menu" branch.

Has it been merged to trunk?

Does anyone know? If not, I'd just delete this branch.

[...]

5. I kept the bs2 and sm branches in the repository  but once the

migration is done, they should be cloned by their owners and should be removed from the main repository.

I can create official Geany repository without them and one clone that contains them so their authors can pick them after the conversion.

Cheers,

Jiri

Le 04/10/2011 23:37, Jiří Techet a écrit :

Hi,

I'm trying to get everything ready for the conversion and there are still a few points unresolved:

...

I have a few comments (and questions) myself:

1. Some branch names should be renamed (e.g. Geany-0_19_1) because

they have the same name as tags and they are ambiguous when doing "git checkout". Some naming scheme for stable branches should be invented.

I was proposing to have two digit branches and three digit tags:

Geany-0_19 - maintenance branch Geany-0_19_0 - tag Geany-0_19_1 - tag Geany-0_19_2 - tag

Do you agree or do you prefer some different naming scheme?

I don't mind much, but it looks sensible since it quite follows current scheme and is clear. So yes, I agree.

...

[...]

3. I haven't found a merge point for the "dynamic-editor-menu" branch.

Has it been merged to trunk?

Does anyone know? If not, I'd just delete this branch.

AFAIK it hasn't been merged, but I'm not sure the code it holds is still relevant, although the idea looks interesting. Maybe Enrico or Nick would know more?

...

[...]

5. I kept the bs2 and sm branches in the repository but once the

migration is done, they should be cloned by their owners and should be removed from the main repository.

I can create official Geany repository without them and one clone that contains them so their authors can pick them after the conversion.

Seems sensible too, since not everybody will (need to) have write access to the official repo, the branches should be in their author's clones. However if one branch is ready yet, it may be not worth the effort of removing and re-getting it? (honestly I don't really know the status of these branches, my bad)

Cheers, Colomban

Le 06/10/2011 22:45, Enrico Tröger a écrit :

On Tue, 04 Oct 2011 23:50:06 +0200, Colomban wrote:

...

Le 04/10/2011 23:37, Jiří Techet a écrit :

...

Hi,

I'm trying to get everything ready for the conversion and there are still a few points unresolved:

...

I have a few comments (and questions) myself:

1. Some branch names should be renamed (e.g. Geany-0_19_1) because

they have the same name as tags and they are ambiguous when doing "git checkout". Some naming scheme for stable branches should be invented.

I was proposing to have two digit branches and three digit tags:

Geany-0_19 - maintenance branch Geany-0_19_0 - tag Geany-0_19_1 - tag Geany-0_19_2 - tag

Do you agree or do you prefer some different naming scheme?

I don't mind much, but it looks sensible since it quite follows current scheme and is clear. So yes, I agree.

What about changing the underscore by a point to make the version number more familiar? I don't remember why I chose the underscore scheme but I know this decision is very, very old. Either it was back in the CVS days or early when migrating from CVS to SVN (this was in late 2005 or early 2006, IIRC). Either I was afraid using points could cause problems or I read somewhere (maybe SF docs) better to use underscores or I was just drunk. Since now, after the GIT merge all references would need to be adjusted at all or they simply die, I guess we can also change the names.

Makes sense, and actually I'd feel more natural by stripping the "Geany-" prefix and replace underscores by dots, eg:

0.19 - maintenance branch for 0.19 (if any) 0.19.0 - first 0.19 release tag 0.19.1 - second 0.19 release tag 0.19.2 - etc.

Actually, I don't see the point of the "Geany-" -- we won't ever release something else than Geany in Geany's repository, right?

Cheers, Colomban

On Thu, 06 Oct 2011 13:59:50 -0700, Matthew wrote:

On 11-10-06 01:55 PM, Colomban Wendling wrote:

...

Makes sense, and actually I'd feel more natural by stripping the "Geany-" prefix and replace underscores by dots, eg:

0.19 - maintenance branch for 0.19 (if any) 0.19.0 - first 0.19 release tag 0.19.1 - second 0.19 release tag 0.19.2 - etc.

Actually, I don't see the point of the "Geany-" -- we won't ever release something else than Geany in Geany's repository, right?

A great extension to my proposal.

+1

+1.

Regards, Enrico

Am 06.10.2011 22:55, schrieb Colomban Wendling:

Le 06/10/2011 22:45, Enrico Tröger a écrit :

...

On Tue, 04 Oct 2011 23:50:06 +0200, Colomban wrote:

...

Le 04/10/2011 23:37, Jiří Techet a écrit :

...

Hi,

I'm trying to get everything ready for the conversion and there are still a few points unresolved:

...

I have a few comments (and questions) myself:

1. Some branch names should be renamed (e.g. Geany-0_19_1) because

they have the same name as tags and they are ambiguous when doing "git checkout". Some naming scheme for stable branches should be invented.

I was proposing to have two digit branches and three digit tags:

Geany-0_19 - maintenance branch Geany-0_19_0 - tag Geany-0_19_1 - tag Geany-0_19_2 - tag

Do you agree or do you prefer some different naming scheme?

I don't mind much, but it looks sensible since it quite follows current scheme and is clear. So yes, I agree.

What about changing the underscore by a point to make the version number more familiar? I don't remember why I chose the underscore scheme but I know this decision is very, very old. Either it was back in the CVS days or early when migrating from CVS to SVN (this was in late 2005 or early 2006, IIRC). Either I was afraid using points could cause problems or I read somewhere (maybe SF docs) better to use underscores or I was just drunk. Since now, after the GIT merge all references would need to be adjusted at all or they simply die, I guess we can also change the names.

Makes sense, and actually I'd feel more natural by stripping the "Geany-" prefix and replace underscores by dots, eg:

0.19 - maintenance branch for 0.19 (if any) 0.19.0 - first 0.19 release tag 0.19.1 - second 0.19 release tag 0.19.2 - etc.

Sounds good.

Cheers, Frank

On Wed, Oct 5, 2011 at 01:02, Matthew Brush mbrush@codebrainz.ca wrote:

On 11-10-04 02:37 PM, Jiří Techet wrote:

...

Hi,

I'm trying to get everything ready for the conversion and there are

Hi Jiri,

I know it's a very small part of what you're doing but I've attached the .gitignore file I made (for the zillionth time) using a combination of the svn:ignore property for each directory and cleaned up by hand.

Maybe it can save you a few minutes :)

Yeah, I have my .gitignore too. Anyway, I don't plan to make any "real" commits during the conversion so it's easier to verify the sources are in the same state as before (on the other hand, this could really speed up the merging of my patches; I'm starting considering it ;-). I'd suggest it should be handled as an ordinary patch by the maintainers after the conversion.

Cheers, Jiri

Am 06.10.2011 11:01, schrieb Jiří Techet:

Yeah, I have my .gitignore too. Anyway, I don't plan to make any "real" commits during the conversion so it's easier to verify the sources are in the same state as before (on the other hand, this could really speed up the merging of my patches; I'm starting considering it ;-). I'd suggest it should be handled as an ordinary patch by the maintainers after the conversion.

Speaking of which, would you be so kind to bring your patches in sync with svn head? I had major headaches trying to do it myself yesterday.

Best regards.

Am 04.10.2011 23:37, schrieb Jiří Techet:

Hi,

I'm trying to get everything ready for the conversion and there are still a few points unresolved:

...

I have a few comments (and questions) myself:

1. Some branch names should be renamed (e.g. Geany-0_19_1) because

they have the same name as tags and they are ambiguous when doing "git checkout". Some naming scheme for stable branches should be invented.

I was proposing to have two digit branches and three digit tags:

Geany-0_19 - maintenance branch Geany-0_19_0 - tag Geany-0_19_1 - tag Geany-0_19_2 - tag

In this case its fine. Also inside the 0.10.x series. But wouldn't define there will be no branch with three digits every.

Do you agree or do you prefer some different naming scheme?

Underscores are just fine.

...

[...]

5. I kept the bs2 and sm branches in the repository but once the

migration is done, they should be cloned by their owners and should be removed from the main repository.

I can create official Geany repository without them and one clone that contains them so their authors can pick them after the conversion.

Sounds good to me.

Cheers, Frank

On Wed, Aug 31, 2011 at 17:21, Colomban Wendling lists.ban@herbesfolles.org wrote:

Hey,

Le 31/08/2011 00:01, Jiří Techet a écrit :

...

On Mon, Aug 29, 2011 at 13:17, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:

...

Am 28.08.2011 23:33, schrieb Jiří Techet:

...

On Sat, Aug 27, 2011 at 20:50, Frank Lanitzfrank@frank.uvena.de  wrote:

...

So I suggest this: Jiri can you help to do so (or does maybe the github svn clone tools does this correct?) we surely can also offer something like that from git.geany.org. But here import is needed FMPOV.

I could, but it needs some manual work and I'd like to do it just before the switch because I'm not sure if I could easily add  the commits (commits on different branches and especially merges) you do between now and the switch. I was too missing a few committer names - see the original email here

http://lists.uvena.de/geany-devel/2010-June/002672.html

which I'd need to get first before performing the conversion.

I could also ask the one that successfully converted our Rockbox svn repo to git, including proper branch, tag and author conversion, to write up the steps it needed. I think it was less than a day of work for him (and the Rockbox tree and history is considerably larger and more complicated than Geany's).

I expect the whole conversion of Geany's vcs wouldn't take more than 4 hours. I believe I know enough to perform the complete conversion myself but of course it would be useful to know someone else's experience.

FWIW, I've played a little with git-svn, and I've got a few things working/non-working:

1. as expected, it doesn't make merges looks like merges, but as a

single commit.  However Thomas said on IRC that SVN didn't knew merges either, maybe it makes this impossible to track then?

Yes, as I said earlier, this has to be adjusted manually by the grafts file.

2. I've got a full commiters list, hopefully OK (that's the only useful

part of this email actually...):

colombanw = Colomban Wendling ban@herbesfolles.org        eht16 = Enrico Tröger enrico.troeger@uvena.de        (no author) = Enrico Tröger enrico.troeger@uvena.de        fralan = Frank Lanitz frank@frank.uvena.de        frlan = Frank Lanitz frank@frank.uvena.de        kretek = Frank Lanitz frank@frank.uvena.de        ntrel = Nick Treleaven nick.treleaven@btinternet.com        dmaphy = Dominic Hopf dmaphy@googlemail.com        statc = Eugene Arshinov earshinov@gmail.com        elextr = Lex Trotman elextr@gmail.com        peterscholtens = Peter Scholtens peter.scholtens@xs4all.nl        clytie = Clytie Siddall clytie@riverland.net.au

Great, good to know.

Frank especially, can you confirm your 3 nicks? (although I've based the matches on SF + commits)

3. We won't probably be able to create Git tags from the SVN tags

because they (at least Geany-0_18 do) don't all tag a single commit (e.g. it's a branch)

If I remember correctly, there should be tags as an output of svn2git. I'd just prefer getting rid of the created tag-branches by rebasing the rest of trunk on top of the tag-branches (for every tag).

Cheers,

Jiri

Hi All,

I recently did a report for a client on DVCSes. Net result was there was a very slight tendency to mistakes with Git (mostly forgetting to git add) but otherwise for normal use there was no material difference between the tools themselves. Nobody who is capable of developing Geany is going to have any trouble with any of them.

On 20 August 2011 07:11, Frank Lanitz frank@frank.uvena.de wrote:

On Fri, 19 Aug 2011 08:57:36 -0500 Josh joshua.rh@comcast.net wrote:

...

@Lex: That makes sense.  After this weekend I'll still have time, but it'll be more sparse.  I'd like to be a part of it; so let me know what we/I need to do to get this going.  Thanks!

1st step: We need to check for points the new system needs to offer (just because github is cool at the moment, I would have a bad feeling if we don't think about what we need before doing anything) and which system might could solve them. There is at least github, gitourios and google code if we just have a view onto git. There are also a couple of services offering hg or bzr which are pretty similar to git. So pretty much I'm looking for a specification sheet with possible matches for solution. I suggest to collect this inside the wiki.

@Frank, the biggest part of the cost of changing is deciding and implementing processes around the new tools. This needs to be investigated *before* any decision on a tool so swap steps 2. and 3. below.

@Matthew, you seem to be up with ways of using the tools, so maybe you can start a wiki page documenting how you see the process working, noting how to handle conflicts between personal branches, still handling patches, integration of things like nightly builds etc. Pretty much anything you write for Git will work with the other two.

As to providers, Hg is available from Google and SF, and now Google offers git as well so thats four for git. Bazaar seems to be SF and Canonical only.

@Enrico & Colomban, when doing the next release what about adding to the page how it would work with a different VCS based on Matthews data, and also how nightly builds and tarballs would work, including with windows. In the end Colomban is the one who has the most to do with it.

2nd step: Decide which system fits best (doodle maybe)

3rd step: Collect what needs to be done in terms of transition. Maybe you can use the wiki for.

4th step: Setting up plan.

Cheers Lex