Re: geany on github; why not?

On 1 September 2011 02:14, Frank Lanitz <frank@...> 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

Re: geany on github; why not?

On Thu, 1 Sep 2011 10:13:38 +1000
Lex Trotman <elextr@...> wrote:

> On 1 September 2011 02:14, Frank Lanitz <frank@...> 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.

Isn't the server also needs to be >1.5? 
Well, however. It appears we just 
don't have this information. 
Cheers, 
Frank 

--

-- 
http://frank.uvena.de/en/

On Thu, 1 Sep 2011 10:13:38 +1000

Include geany-themes before release?

Hi,

Should we add (parts of) the geany-themes[1] project to Geany before the 
release freeze for 0.21?  If so, I propose that we add all the filedefs, 
the alt.conf theme, one light theme, and one dark theme.

If nobody is opposed, I will prepare a patch in short order.

P.S. I just added some info about geany-themes on the colour schemes 
section of the wiki[2].

[1] https://github.com/codebrainz/geany-themes
[2] https://wiki.geany.org/themes/start

Cheers,
Matthew Brush

Re: Include geany-themes before release?

On 3 September 2011 15:41, Matthew Brush <mbrush@...> wrote:
> Hi,
>
> Should we add (parts of) the geany-themes[1] project to Geany before the
> release freeze for 0.21?  If so, I propose that we add all the filedefs, the
> alt.conf theme, one light theme, and one dark theme.

Why would we want to add any of these virulent examples of bad taste
to a classy project like Geany? ;-P

On the other hand people who use them deserve the seared retinas so why not 

>
> If nobody is opposed, I will prepare a patch in short order.
>

My greater concern will be to ensure that replacing all the filedefs
just before release doesn't break anything.

I guess it will have to be an inspection of the diffs in the patch to
check that only the look is changed, since every file is changed.

And also that you haven't snuck in any changes to the default theme. 

> P.S. I just added some info about geany-themes on the colour schemes section
> of the wiki[2].

One thing you need to note is that installing themes by copying
filetypes.* to .config/geany will erase any filetype command settings
you have made.  A problem to fix one day.

Re: Include geany-themes before release?

On Sat, 3 Sep 2011 16:43:44 +1000
Lex Trotman <elextr@...> wrote:

> >
> > If nobody is opposed, I will prepare a patch in short order.
> >
> 
> My greater concern will be to ensure that replacing all the filedefs
> just before release doesn't break anything.
> 
> I guess it will have to be an inspection of the diffs in the patch to
> check that only the look is changed, since every file is changed.
> 
> And also that you haven't snuck in any changes to the default
> theme. 

I'd prefer to move it post release in case we want to do it. 

Cheers, 
Frank
--

-- 
http://frank.uvena.de/en/

On Sat, 3 Sep 2011 16:43:44 +1000
Lex Trotman <elextr@...> wrote:

> >
> > If nobody is opposed, I will prepare a patch in short order.
> >

Re: geany on github; why not?

On Wed, Aug 31, 2011 at 18:41, Colomban Wendling
<lists.ban <at> herbesfolles.org> wrote:
> 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 :)
>

Hi,

I've finally had some time to experiment a bit more with the svn->git
conversion and I'm quite satisfied with the result. This is what I

Re: geany on github; why not?

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:
>

Re: geany on github; why not?

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

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

Cheers
Lex

Re: geany on github; why not?

On Tue, Sep 6, 2011 at 05:29, Lex Trotman <elextr <at> gmail.com> wrote:
> 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.

Yes, exactly, one could play with the repository almost infinitely to
make it look beautiful but then it makes no difference in reality.

>>
>> 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).
>

There are actually three different naming schemes for stable branches now:

0.20.1

Re: geany on github; why not?

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