[Discuss] Migrate JMeter from SVN ASF repo to GIT ASF repo

[Milamber <mi...@apache.org>]

Hello,

I would like open a discussion for the opportunity to migrate the JMeter 
svn repo into the git repository of ASF.

Why (IMHO)?
- because the usage of git seems more easier to make some operations 
like merge or revert a commit
- the possibility to merge a pull request from Github is very easy (for 
example, merge a PR to a local branch, tests and if error comment the PR)
- Allow to create several local branches to test patches from buzgilla, 
make some dev/enhancements on JMeter locally and after the final line 
code, do a PR on Github
- The strong integration between Git and Github and the increasing 
number of developers using github to do a PR on open source projects 
(and the easy way to to that)

Some consequences:
The release process must change (tag/rc branch and the publishing of the 
web site)
The website must be updated on the Developers informations

Any thoughts?

Milamber

Re: [Discuss] Migrate JMeter from SVN ASF repo to GIT ASF repo

[sebb <se...@gmail.com>]

On 17 October 2015 at 14:37, Philippe Mouawad
<ph...@gmail.com> wrote:
> Hi,
> What's the status on this ?

There are some missing features in Git for which no alternatives have
been provided.

> What's the opinion of the rest of the dev team ?
>
> Thanks
>
>
> On Sat, Oct 3, 2015 at 1:49 PM, Philippe Mouawad <philippe.mouawad@gmail.com
>> wrote:
>
>> Hello,
>> +1 for me to migrate to GIT.
>>
>> I think it's a great way to encourage contributions.
>> It will also make it easier for us to work on medium to large features as
>> git merge is really powerful.
>>
>> Many Apaches projet are doing it currently and I think we should follow
>> this movement.
>>
>> Regards
>> Philippe
>>
>> On Tue, Aug 25, 2015 at 8:19 PM, Andrey Ponomarev <
>> andrey.ponomarev@gmail.com> wrote:
>>
>>> On Tue, Aug 25, 2015 at 6:21 PM, sebb <se...@gmail.com> wrote:
>>>
>>> > On 25 August 2015 at 17:06, Andrey Ponomarev <
>>> andrey.ponomarev@gmail.com>
>>> > wrote:
>>> > > On Tue, Aug 25, 2015 at 4:25 PM, sebb <se...@gmail.com> wrote:
>>> > >
>>> > >>
>>> > >> >> However there are areas of the build and testing that rely on
>>> being
>>> > >> >> able to access the revision number of a file.
>>> > >> >> That is impossible in Git as far as I know.
>>> > >> >>
>>> > >> >
>>> > >> > Git has commit hashes. They play the same role as revision numbers
>>> in
>>> > SVN
>>> > >> > One can checkout the whole commit or an individual file of any
>>> commit
>>> > if
>>> > >> > needed.
>>> > >>
>>> > >> That is not what I meant.
>>> > >> The code and build file use the current revision of the file, e.g.
>>> > >> @revision.
>>> > >> This is automatically updated when a file is checked out.
>>> > >>
>>> > >
>>> > > I've looked into build.xml and found svn.revision property.  If this
>>> is
>>> > > what you mean, then I don't see any difference in using commit hash
>>> > instead.
>>> >
>>> > No, that's only one aspect of the issue.
>>> > Some files use the revision number of the file they are compiled from
>>> > in their code.
>>> > As I already wrote, the file can contain the string @revision and this
>>> > will be replaced by
>>> > the revision number on checkout.
>>> > This number is used for test checks and for info in output files.
>>> >
>>>
>>> I think I got it finally. You must be talking about $Revision$ in source
>>> files.
>>> Then yes, you are right, git don't modify source code before commit.
>>>
>>> There a few possible workarounds come into my mind:
>>> - write an ant task that will insert/replace the hash;
>>> - write git checkout/commit hooks that will replace the value.
>>> None of this workarounds is as good as SVN feature.
>>>
>>> On the other hand, the use of @version in javadocs is questionable.
>>> First, the full hash in every source file will look really ugly.
>>> Secondly, developer always knows the revision s/he is working with.
>>>
>>>
>>>
>>> > > The hash is obviously longer than svn revision number. Though first
>>> few
>>> > > characters are enough for git, so you don't need to type the whole
>>> hash.
>>> > > You can use "exec" task for calling "git rev-parse HEAD". That will
>>> > return
>>> > > the current revision (hash).
>>> > > Is it what you mean?
>>> >
>>> > No, see above.
>>> >
>>> > >
>>> > >
>>> > >> So how do you configure some files as native, some as CRLF and some
>>> as
>>> > LF?
>>> > >> This is trivial in SVN, and the settings stay with the file.
>>> > >>
>>> > >
>>> > > Create a file called ".gitattributes" in the project root. In this
>>> file
>>> > you
>>> > > can specify attributes for files, including line endings.
>>> > > Here is modified example from github article "Dealing with line
>>> endings":
>>> > >
>>> > > # Set the default behavior, in case people don't have core.autocrlf
>>> set.
>>> > > * text=auto
>>> > >
>>> > > # Explicitly declare text files you want to always be normalized and
>>> > > converted
>>> > > # to native line endings on checkout.
>>> > > *.java text
>>> > >
>>> > > # Declare files that will always have CRLF line endings on checkout.
>>> > > *.cmd text eol=crlf
>>> > > *.bat text eol=crlf
>>> > >
>>> > > # Declare files that will always have LF line endings on checkout.
>>> > > *.sh eol=lf
>>> > >
>>> > > # Denote all files that are truly binary and should not be modified.
>>> > > *.png binary
>>> > > *.jpg binary
>>> >
>>> > Again, that's not as flexible as SVN.
>>> > As I recall, not all files with the same extension need the same EOL.
>>> > So the property needs to be attached to the file, not in a separate text
>>> > file.
>>> >
>>>
>>> You can specify exact file name. It's not that flexible as SVN, I agree.
>>> If you rename the file, you may forget to update .gitattributes
>>> On the other hand the information about EOL is kept in source code instead
>>> of version control. I find it beneficial.
>>>
>>>
>>>  /Andrey
>>>
>>
>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
>>
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: [Discuss] Migrate JMeter from SVN ASF repo to GIT ASF repo

[Philippe Mouawad <ph...@gmail.com>]

Hi,
Just so that it's clear to everybody in the future, I understand issues are
the following:
- EOL
- Revision number : Are we talking about
SaveService.java/saveservice.properties or are there other things
- Build fills in the revision information which could also be a git commit
id

Are there any other issues ? If so @sebb, could you point the exact places
you know about (classes , files) ?

Reading the thread it's not fully clear to me.

Thanks

On Sat, Oct 17, 2015 at 5:47 PM, Felix Schumacher <
felix.schumacher@internetallee.de> wrote:

>
>
> Am 17. Oktober 2015 15:37:19 MESZ, schrieb Philippe Mouawad <
> philippe.mouawad@gmail.com>:
> >Hi,
> >What's the status on this ?
> >
> >What's the opinion of the rest of the dev team ?
>
> While I really like git and use it for my own work on jmeter, I don't see
> that much of an improvement over svn for our model of work. Which is one
> main trunk where only small changes are getting merged.
>
> The nice features that are provided by github can be used already to a
> great extend.
>
> There are a few things for which replacement would have to be found, as
> sebb already mentioned.
>
> And someone would have to do the work of conversion.
>
> Given all these points I am +-0 on this.
>
> Regards,
> Felix
>
> >
> >Thanks
> >
> >
> >On Sat, Oct 3, 2015 at 1:49 PM, Philippe Mouawad
> ><philippe.mouawad@gmail.com
> >> wrote:
> >
> >> Hello,
> >> +1 for me to migrate to GIT.
> >>
> >> I think it's a great way to encourage contributions.
> >> It will also make it easier for us to work on medium to large
> >features as
> >> git merge is really powerful.
> >>
> >> Many Apaches projet are doing it currently and I think we should
> >follow
> >> this movement.
> >>
> >> Regards
> >> Philippe
> >>
> >> On Tue, Aug 25, 2015 at 8:19 PM, Andrey Ponomarev <
> >> andrey.ponomarev@gmail.com> wrote:
> >>
> >>> On Tue, Aug 25, 2015 at 6:21 PM, sebb <se...@gmail.com> wrote:
> >>>
> >>> > On 25 August 2015 at 17:06, Andrey Ponomarev <
> >>> andrey.ponomarev@gmail.com>
> >>> > wrote:
> >>> > > On Tue, Aug 25, 2015 at 4:25 PM, sebb <se...@gmail.com> wrote:
> >>> > >
> >>> > >>
> >>> > >> >> However there are areas of the build and testing that rely
> >on
> >>> being
> >>> > >> >> able to access the revision number of a file.
> >>> > >> >> That is impossible in Git as far as I know.
> >>> > >> >>
> >>> > >> >
> >>> > >> > Git has commit hashes. They play the same role as revision
> >numbers
> >>> in
> >>> > SVN
> >>> > >> > One can checkout the whole commit or an individual file of
> >any
> >>> commit
> >>> > if
> >>> > >> > needed.
> >>> > >>
> >>> > >> That is not what I meant.
> >>> > >> The code and build file use the current revision of the file,
> >e.g.
> >>> > >> @revision.
> >>> > >> This is automatically updated when a file is checked out.
> >>> > >>
> >>> > >
> >>> > > I've looked into build.xml and found svn.revision property.  If
> >this
> >>> is
> >>> > > what you mean, then I don't see any difference in using commit
> >hash
> >>> > instead.
> >>> >
> >>> > No, that's only one aspect of the issue.
> >>> > Some files use the revision number of the file they are compiled
> >from
> >>> > in their code.
> >>> > As I already wrote, the file can contain the string @revision and
> >this
> >>> > will be replaced by
> >>> > the revision number on checkout.
> >>> > This number is used for test checks and for info in output files.
> >>> >
> >>>
> >>> I think I got it finally. You must be talking about $Revision$ in
> >source
> >>> files.
> >>> Then yes, you are right, git don't modify source code before commit.
> >>>
> >>> There a few possible workarounds come into my mind:
> >>> - write an ant task that will insert/replace the hash;
> >>> - write git checkout/commit hooks that will replace the value.
> >>> None of this workarounds is as good as SVN feature.
> >>>
> >>> On the other hand, the use of @version in javadocs is questionable.
> >>> First, the full hash in every source file will look really ugly.
> >>> Secondly, developer always knows the revision s/he is working with.
> >>>
> >>>
> >>>
> >>> > > The hash is obviously longer than svn revision number. Though
> >first
> >>> few
> >>> > > characters are enough for git, so you don't need to type the
> >whole
> >>> hash.
> >>> > > You can use "exec" task for calling "git rev-parse HEAD". That
> >will
> >>> > return
> >>> > > the current revision (hash).
> >>> > > Is it what you mean?
> >>> >
> >>> > No, see above.
> >>> >
> >>> > >
> >>> > >
> >>> > >> So how do you configure some files as native, some as CRLF and
> >some
> >>> as
> >>> > LF?
> >>> > >> This is trivial in SVN, and the settings stay with the file.
> >>> > >>
> >>> > >
> >>> > > Create a file called ".gitattributes" in the project root. In
> >this
> >>> file
> >>> > you
> >>> > > can specify attributes for files, including line endings.
> >>> > > Here is modified example from github article "Dealing with line
> >>> endings":
> >>> > >
> >>> > > # Set the default behavior, in case people don't have
> >core.autocrlf
> >>> set.
> >>> > > * text=auto
> >>> > >
> >>> > > # Explicitly declare text files you want to always be normalized
> >and
> >>> > > converted
> >>> > > # to native line endings on checkout.
> >>> > > *.java text
> >>> > >
> >>> > > # Declare files that will always have CRLF line endings on
> >checkout.
> >>> > > *.cmd text eol=crlf
> >>> > > *.bat text eol=crlf
> >>> > >
> >>> > > # Declare files that will always have LF line endings on
> >checkout.
> >>> > > *.sh eol=lf
> >>> > >
> >>> > > # Denote all files that are truly binary and should not be
> >modified.
> >>> > > *.png binary
> >>> > > *.jpg binary
> >>> >
> >>> > Again, that's not as flexible as SVN.
> >>> > As I recall, not all files with the same extension need the same
> >EOL.
> >>> > So the property needs to be attached to the file, not in a
> >separate text
> >>> > file.
> >>> >
> >>>
> >>> You can specify exact file name. It's not that flexible as SVN, I
> >agree.
> >>> If you rename the file, you may forget to update .gitattributes
> >>> On the other hand the information about EOL is kept in source code
> >instead
> >>> of version control. I find it beneficial.
> >>>
> >>>
> >>>  /Andrey
> >>>
> >>
> >>
> >>
> >> --
> >> Cordialement.
> >> Philippe Mouawad.
> >>
> >>
> >>
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: [Discuss] Migrate JMeter from SVN ASF repo to GIT ASF repo

[Felix Schumacher <fe...@internetallee.de>]

Am 17. Oktober 2015 15:37:19 MESZ, schrieb Philippe Mouawad <ph...@gmail.com>:
>Hi,
>What's the status on this ?
>
>What's the opinion of the rest of the dev team ?

While I really like git and use it for my own work on jmeter, I don't see that much of an improvement over svn for our model of work. Which is one main trunk where only small changes are getting merged.

The nice features that are provided by github can be used already to a great extend. 

There are a few things for which replacement would have to be found, as sebb already mentioned. 

And someone would have to do the work of conversion. 

Given all these points I am +-0 on this.

Regards, 
Felix 

>
>Thanks
>
>
>On Sat, Oct 3, 2015 at 1:49 PM, Philippe Mouawad
><philippe.mouawad@gmail.com
>> wrote:
>
>> Hello,
>> +1 for me to migrate to GIT.
>>
>> I think it's a great way to encourage contributions.
>> It will also make it easier for us to work on medium to large
>features as
>> git merge is really powerful.
>>
>> Many Apaches projet are doing it currently and I think we should
>follow
>> this movement.
>>
>> Regards
>> Philippe
>>
>> On Tue, Aug 25, 2015 at 8:19 PM, Andrey Ponomarev <
>> andrey.ponomarev@gmail.com> wrote:
>>
>>> On Tue, Aug 25, 2015 at 6:21 PM, sebb <se...@gmail.com> wrote:
>>>
>>> > On 25 August 2015 at 17:06, Andrey Ponomarev <
>>> andrey.ponomarev@gmail.com>
>>> > wrote:
>>> > > On Tue, Aug 25, 2015 at 4:25 PM, sebb <se...@gmail.com> wrote:
>>> > >
>>> > >>
>>> > >> >> However there are areas of the build and testing that rely
>on
>>> being
>>> > >> >> able to access the revision number of a file.
>>> > >> >> That is impossible in Git as far as I know.
>>> > >> >>
>>> > >> >
>>> > >> > Git has commit hashes. They play the same role as revision
>numbers
>>> in
>>> > SVN
>>> > >> > One can checkout the whole commit or an individual file of
>any
>>> commit
>>> > if
>>> > >> > needed.
>>> > >>
>>> > >> That is not what I meant.
>>> > >> The code and build file use the current revision of the file,
>e.g.
>>> > >> @revision.
>>> > >> This is automatically updated when a file is checked out.
>>> > >>
>>> > >
>>> > > I've looked into build.xml and found svn.revision property.  If
>this
>>> is
>>> > > what you mean, then I don't see any difference in using commit
>hash
>>> > instead.
>>> >
>>> > No, that's only one aspect of the issue.
>>> > Some files use the revision number of the file they are compiled
>from
>>> > in their code.
>>> > As I already wrote, the file can contain the string @revision and
>this
>>> > will be replaced by
>>> > the revision number on checkout.
>>> > This number is used for test checks and for info in output files.
>>> >
>>>
>>> I think I got it finally. You must be talking about $Revision$ in
>source
>>> files.
>>> Then yes, you are right, git don't modify source code before commit.
>>>
>>> There a few possible workarounds come into my mind:
>>> - write an ant task that will insert/replace the hash;
>>> - write git checkout/commit hooks that will replace the value.
>>> None of this workarounds is as good as SVN feature.
>>>
>>> On the other hand, the use of @version in javadocs is questionable.
>>> First, the full hash in every source file will look really ugly.
>>> Secondly, developer always knows the revision s/he is working with.
>>>
>>>
>>>
>>> > > The hash is obviously longer than svn revision number. Though
>first
>>> few
>>> > > characters are enough for git, so you don't need to type the
>whole
>>> hash.
>>> > > You can use "exec" task for calling "git rev-parse HEAD". That
>will
>>> > return
>>> > > the current revision (hash).
>>> > > Is it what you mean?
>>> >
>>> > No, see above.
>>> >
>>> > >
>>> > >
>>> > >> So how do you configure some files as native, some as CRLF and
>some
>>> as
>>> > LF?
>>> > >> This is trivial in SVN, and the settings stay with the file.
>>> > >>
>>> > >
>>> > > Create a file called ".gitattributes" in the project root. In
>this
>>> file
>>> > you
>>> > > can specify attributes for files, including line endings.
>>> > > Here is modified example from github article "Dealing with line
>>> endings":
>>> > >
>>> > > # Set the default behavior, in case people don't have
>core.autocrlf
>>> set.
>>> > > * text=auto
>>> > >
>>> > > # Explicitly declare text files you want to always be normalized
>and
>>> > > converted
>>> > > # to native line endings on checkout.
>>> > > *.java text
>>> > >
>>> > > # Declare files that will always have CRLF line endings on
>checkout.
>>> > > *.cmd text eol=crlf
>>> > > *.bat text eol=crlf
>>> > >
>>> > > # Declare files that will always have LF line endings on
>checkout.
>>> > > *.sh eol=lf
>>> > >
>>> > > # Denote all files that are truly binary and should not be
>modified.
>>> > > *.png binary
>>> > > *.jpg binary
>>> >
>>> > Again, that's not as flexible as SVN.
>>> > As I recall, not all files with the same extension need the same
>EOL.
>>> > So the property needs to be attached to the file, not in a
>separate text
>>> > file.
>>> >
>>>
>>> You can specify exact file name. It's not that flexible as SVN, I
>agree.
>>> If you rename the file, you may forget to update .gitattributes
>>> On the other hand the information about EOL is kept in source code
>instead
>>> of version control. I find it beneficial.
>>>
>>>
>>>  /Andrey
>>>
>>
>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
>>
>>
>>

Re: [Discuss] Migrate JMeter from SVN ASF repo to GIT ASF repo

[Philippe Mouawad <ph...@gmail.com>]

Hi,
What's the status on this ?

What's the opinion of the rest of the dev team ?

Thanks


On Sat, Oct 3, 2015 at 1:49 PM, Philippe Mouawad <philippe.mouawad@gmail.com
> wrote:

> Hello,
> +1 for me to migrate to GIT.
>
> I think it's a great way to encourage contributions.
> It will also make it easier for us to work on medium to large features as
> git merge is really powerful.
>
> Many Apaches projet are doing it currently and I think we should follow
> this movement.
>
> Regards
> Philippe
>
> On Tue, Aug 25, 2015 at 8:19 PM, Andrey Ponomarev <
> andrey.ponomarev@gmail.com> wrote:
>
>> On Tue, Aug 25, 2015 at 6:21 PM, sebb <se...@gmail.com> wrote:
>>
>> > On 25 August 2015 at 17:06, Andrey Ponomarev <
>> andrey.ponomarev@gmail.com>
>> > wrote:
>> > > On Tue, Aug 25, 2015 at 4:25 PM, sebb <se...@gmail.com> wrote:
>> > >
>> > >>
>> > >> >> However there are areas of the build and testing that rely on
>> being
>> > >> >> able to access the revision number of a file.
>> > >> >> That is impossible in Git as far as I know.
>> > >> >>
>> > >> >
>> > >> > Git has commit hashes. They play the same role as revision numbers
>> in
>> > SVN
>> > >> > One can checkout the whole commit or an individual file of any
>> commit
>> > if
>> > >> > needed.
>> > >>
>> > >> That is not what I meant.
>> > >> The code and build file use the current revision of the file, e.g.
>> > >> @revision.
>> > >> This is automatically updated when a file is checked out.
>> > >>
>> > >
>> > > I've looked into build.xml and found svn.revision property.  If this
>> is
>> > > what you mean, then I don't see any difference in using commit hash
>> > instead.
>> >
>> > No, that's only one aspect of the issue.
>> > Some files use the revision number of the file they are compiled from
>> > in their code.
>> > As I already wrote, the file can contain the string @revision and this
>> > will be replaced by
>> > the revision number on checkout.
>> > This number is used for test checks and for info in output files.
>> >
>>
>> I think I got it finally. You must be talking about $Revision$ in source
>> files.
>> Then yes, you are right, git don't modify source code before commit.
>>
>> There a few possible workarounds come into my mind:
>> - write an ant task that will insert/replace the hash;
>> - write git checkout/commit hooks that will replace the value.
>> None of this workarounds is as good as SVN feature.
>>
>> On the other hand, the use of @version in javadocs is questionable.
>> First, the full hash in every source file will look really ugly.
>> Secondly, developer always knows the revision s/he is working with.
>>
>>
>>
>> > > The hash is obviously longer than svn revision number. Though first
>> few
>> > > characters are enough for git, so you don't need to type the whole
>> hash.
>> > > You can use "exec" task for calling "git rev-parse HEAD". That will
>> > return
>> > > the current revision (hash).
>> > > Is it what you mean?
>> >
>> > No, see above.
>> >
>> > >
>> > >
>> > >> So how do you configure some files as native, some as CRLF and some
>> as
>> > LF?
>> > >> This is trivial in SVN, and the settings stay with the file.
>> > >>
>> > >
>> > > Create a file called ".gitattributes" in the project root. In this
>> file
>> > you
>> > > can specify attributes for files, including line endings.
>> > > Here is modified example from github article "Dealing with line
>> endings":
>> > >
>> > > # Set the default behavior, in case people don't have core.autocrlf
>> set.
>> > > * text=auto
>> > >
>> > > # Explicitly declare text files you want to always be normalized and
>> > > converted
>> > > # to native line endings on checkout.
>> > > *.java text
>> > >
>> > > # Declare files that will always have CRLF line endings on checkout.
>> > > *.cmd text eol=crlf
>> > > *.bat text eol=crlf
>> > >
>> > > # Declare files that will always have LF line endings on checkout.
>> > > *.sh eol=lf
>> > >
>> > > # Denote all files that are truly binary and should not be modified.
>> > > *.png binary
>> > > *.jpg binary
>> >
>> > Again, that's not as flexible as SVN.
>> > As I recall, not all files with the same extension need the same EOL.
>> > So the property needs to be attached to the file, not in a separate text
>> > file.
>> >
>>
>> You can specify exact file name. It's not that flexible as SVN, I agree.
>> If you rename the file, you may forget to update .gitattributes
>> On the other hand the information about EOL is kept in source code instead
>> of version control. I find it beneficial.
>>
>>
>>  /Andrey
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: [Discuss] Migrate JMeter from SVN ASF repo to GIT ASF repo

[Philippe Mouawad <ph...@gmail.com>]

Hello,
+1 for me to migrate to GIT.

I think it's a great way to encourage contributions.
It will also make it easier for us to work on medium to large features as
git merge is really powerful.

Many Apaches projet are doing it currently and I think we should follow
this movement.

Regards
Philippe

On Tue, Aug 25, 2015 at 8:19 PM, Andrey Ponomarev <
andrey.ponomarev@gmail.com> wrote:

> On Tue, Aug 25, 2015 at 6:21 PM, sebb <se...@gmail.com> wrote:
>
> > On 25 August 2015 at 17:06, Andrey Ponomarev <andrey.ponomarev@gmail.com
> >
> > wrote:
> > > On Tue, Aug 25, 2015 at 4:25 PM, sebb <se...@gmail.com> wrote:
> > >
> > >>
> > >> >> However there are areas of the build and testing that rely on being
> > >> >> able to access the revision number of a file.
> > >> >> That is impossible in Git as far as I know.
> > >> >>
> > >> >
> > >> > Git has commit hashes. They play the same role as revision numbers
> in
> > SVN
> > >> > One can checkout the whole commit or an individual file of any
> commit
> > if
> > >> > needed.
> > >>
> > >> That is not what I meant.
> > >> The code and build file use the current revision of the file, e.g.
> > >> @revision.
> > >> This is automatically updated when a file is checked out.
> > >>
> > >
> > > I've looked into build.xml and found svn.revision property.  If this is
> > > what you mean, then I don't see any difference in using commit hash
> > instead.
> >
> > No, that's only one aspect of the issue.
> > Some files use the revision number of the file they are compiled from
> > in their code.
> > As I already wrote, the file can contain the string @revision and this
> > will be replaced by
> > the revision number on checkout.
> > This number is used for test checks and for info in output files.
> >
>
> I think I got it finally. You must be talking about $Revision$ in source
> files.
> Then yes, you are right, git don't modify source code before commit.
>
> There a few possible workarounds come into my mind:
> - write an ant task that will insert/replace the hash;
> - write git checkout/commit hooks that will replace the value.
> None of this workarounds is as good as SVN feature.
>
> On the other hand, the use of @version in javadocs is questionable.
> First, the full hash in every source file will look really ugly.
> Secondly, developer always knows the revision s/he is working with.
>
>
>
> > > The hash is obviously longer than svn revision number. Though first few
> > > characters are enough for git, so you don't need to type the whole
> hash.
> > > You can use "exec" task for calling "git rev-parse HEAD". That will
> > return
> > > the current revision (hash).
> > > Is it what you mean?
> >
> > No, see above.
> >
> > >
> > >
> > >> So how do you configure some files as native, some as CRLF and some as
> > LF?
> > >> This is trivial in SVN, and the settings stay with the file.
> > >>
> > >
> > > Create a file called ".gitattributes" in the project root. In this file
> > you
> > > can specify attributes for files, including line endings.
> > > Here is modified example from github article "Dealing with line
> endings":
> > >
> > > # Set the default behavior, in case people don't have core.autocrlf
> set.
> > > * text=auto
> > >
> > > # Explicitly declare text files you want to always be normalized and
> > > converted
> > > # to native line endings on checkout.
> > > *.java text
> > >
> > > # Declare files that will always have CRLF line endings on checkout.
> > > *.cmd text eol=crlf
> > > *.bat text eol=crlf
> > >
> > > # Declare files that will always have LF line endings on checkout.
> > > *.sh eol=lf
> > >
> > > # Denote all files that are truly binary and should not be modified.
> > > *.png binary
> > > *.jpg binary
> >
> > Again, that's not as flexible as SVN.
> > As I recall, not all files with the same extension need the same EOL.
> > So the property needs to be attached to the file, not in a separate text
> > file.
> >
>
> You can specify exact file name. It's not that flexible as SVN, I agree.
> If you rename the file, you may forget to update .gitattributes
> On the other hand the information about EOL is kept in source code instead
> of version control. I find it beneficial.
>
>
>  /Andrey
>



-- 
Cordialement.
Philippe Mouawad.

Re: [Discuss] Migrate JMeter from SVN ASF repo to GIT ASF repo

[Andrey Ponomarev <an...@gmail.com>]

On Tue, Aug 25, 2015 at 6:21 PM, sebb <se...@gmail.com> wrote:

> On 25 August 2015 at 17:06, Andrey Ponomarev <an...@gmail.com>
> wrote:
> > On Tue, Aug 25, 2015 at 4:25 PM, sebb <se...@gmail.com> wrote:
> >
> >>
> >> >> However there are areas of the build and testing that rely on being
> >> >> able to access the revision number of a file.
> >> >> That is impossible in Git as far as I know.
> >> >>
> >> >
> >> > Git has commit hashes. They play the same role as revision numbers in
> SVN
> >> > One can checkout the whole commit or an individual file of any commit
> if
> >> > needed.
> >>
> >> That is not what I meant.
> >> The code and build file use the current revision of the file, e.g.
> >> @revision.
> >> This is automatically updated when a file is checked out.
> >>
> >
> > I've looked into build.xml and found svn.revision property.  If this is
> > what you mean, then I don't see any difference in using commit hash
> instead.
>
> No, that's only one aspect of the issue.
> Some files use the revision number of the file they are compiled from
> in their code.
> As I already wrote, the file can contain the string @revision and this
> will be replaced by
> the revision number on checkout.
> This number is used for test checks and for info in output files.
>

I think I got it finally. You must be talking about $Revision$ in source
files.
Then yes, you are right, git don't modify source code before commit.

There a few possible workarounds come into my mind:
- write an ant task that will insert/replace the hash;
- write git checkout/commit hooks that will replace the value.
None of this workarounds is as good as SVN feature.

On the other hand, the use of @version in javadocs is questionable.
First, the full hash in every source file will look really ugly.
Secondly, developer always knows the revision s/he is working with.



> > The hash is obviously longer than svn revision number. Though first few
> > characters are enough for git, so you don't need to type the whole hash.
> > You can use "exec" task for calling "git rev-parse HEAD". That will
> return
> > the current revision (hash).
> > Is it what you mean?
>
> No, see above.
>
> >
> >
> >> So how do you configure some files as native, some as CRLF and some as
> LF?
> >> This is trivial in SVN, and the settings stay with the file.
> >>
> >
> > Create a file called ".gitattributes" in the project root. In this file
> you
> > can specify attributes for files, including line endings.
> > Here is modified example from github article "Dealing with line endings":
> >
> > # Set the default behavior, in case people don't have core.autocrlf set.
> > * text=auto
> >
> > # Explicitly declare text files you want to always be normalized and
> > converted
> > # to native line endings on checkout.
> > *.java text
> >
> > # Declare files that will always have CRLF line endings on checkout.
> > *.cmd text eol=crlf
> > *.bat text eol=crlf
> >
> > # Declare files that will always have LF line endings on checkout.
> > *.sh eol=lf
> >
> > # Denote all files that are truly binary and should not be modified.
> > *.png binary
> > *.jpg binary
>
> Again, that's not as flexible as SVN.
> As I recall, not all files with the same extension need the same EOL.
> So the property needs to be attached to the file, not in a separate text
> file.
>

You can specify exact file name. It's not that flexible as SVN, I agree.
If you rename the file, you may forget to update .gitattributes
On the other hand the information about EOL is kept in source code instead
of version control. I find it beneficial.


 /Andrey

Re: [Discuss] Migrate JMeter from SVN ASF repo to GIT ASF repo

[sebb <se...@gmail.com>]

On 25 August 2015 at 17:06, Andrey Ponomarev <an...@gmail.com> wrote:
> On Tue, Aug 25, 2015 at 4:25 PM, sebb <se...@gmail.com> wrote:
>
>>
>> >> However there are areas of the build and testing that rely on being
>> >> able to access the revision number of a file.
>> >> That is impossible in Git as far as I know.
>> >>
>> >
>> > Git has commit hashes. They play the same role as revision numbers in SVN
>> > One can checkout the whole commit or an individual file of any commit if
>> > needed.
>>
>> That is not what I meant.
>> The code and build file use the current revision of the file, e.g.
>> @revision.
>> This is automatically updated when a file is checked out.
>>
>
> I've looked into build.xml and found svn.revision property.  If this is
> what you mean, then I don't see any difference in using commit hash instead.

No, that's only one aspect of the issue.
Some files use the revision number of the file they are compiled from
in their code.
As I already wrote, the file can contain the string @revision and this
will be replaced by
the revision number on checkout.
This number is used for test checks and for info in output files.

> The hash is obviously longer than svn revision number. Though first few
> characters are enough for git, so you don't need to type the whole hash.
> You can use "exec" task for calling "git rev-parse HEAD". That will return
> the current revision (hash).
> Is it what you mean?

No, see above.

>
>
>> So how do you configure some files as native, some as CRLF and some as LF?
>> This is trivial in SVN, and the settings stay with the file.
>>
>
> Create a file called ".gitattributes" in the project root. In this file you
> can specify attributes for files, including line endings.
> Here is modified example from github article "Dealing with line endings":
>
> # Set the default behavior, in case people don't have core.autocrlf set.
> * text=auto
>
> # Explicitly declare text files you want to always be normalized and
> converted
> # to native line endings on checkout.
> *.java text
>
> # Declare files that will always have CRLF line endings on checkout.
> *.cmd text eol=crlf
> *.bat text eol=crlf
>
> # Declare files that will always have LF line endings on checkout.
> *.sh eol=lf
>
> # Denote all files that are truly binary and should not be modified.
> *.png binary
> *.jpg binary

Again, that's not as flexible as SVN.
As I recall, not all files with the same extension need the same EOL.
So the property needs to be attached to the file, not in a separate text file.

>
> /Andrey

Re: [Discuss] Migrate JMeter from SVN ASF repo to GIT ASF repo

[Andrey Ponomarev <an...@gmail.com>]

On Tue, Aug 25, 2015 at 4:25 PM, sebb <se...@gmail.com> wrote:

>
> >> However there are areas of the build and testing that rely on being
> >> able to access the revision number of a file.
> >> That is impossible in Git as far as I know.
> >>
> >
> > Git has commit hashes. They play the same role as revision numbers in SVN
> > One can checkout the whole commit or an individual file of any commit if
> > needed.
>
> That is not what I meant.
> The code and build file use the current revision of the file, e.g.
> @revision.
> This is automatically updated when a file is checked out.
>

I've looked into build.xml and found svn.revision property.  If this is
what you mean, then I don't see any difference in using commit hash instead.
The hash is obviously longer than svn revision number. Though first few
characters are enough for git, so you don't need to type the whole hash.
You can use "exec" task for calling "git rev-parse HEAD". That will return
the current revision (hash).
Is it what you mean?



> So how do you configure some files as native, some as CRLF and some as LF?
> This is trivial in SVN, and the settings stay with the file.
>

Create a file called ".gitattributes" in the project root. In this file you
can specify attributes for files, including line endings.
Here is modified example from github article "Dealing with line endings":

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

# Explicitly declare text files you want to always be normalized and
converted
# to native line endings on checkout.
*.java text

# Declare files that will always have CRLF line endings on checkout.
*.cmd text eol=crlf
*.bat text eol=crlf

# Declare files that will always have LF line endings on checkout.
*.sh eol=lf

# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary


/Andrey

Re: [Discuss] Migrate JMeter from SVN ASF repo to GIT ASF repo

[sebb <se...@gmail.com>]

On 25 August 2015 at 15:03, Andrey Ponomarev <an...@gmail.com> wrote:
> On Tue, Aug 25, 2015 at 3:34 PM, sebb <se...@gmail.com> wrote:
>
>> However there are areas of the build and testing that rely on being
>> able to access the revision number of a file.
>> That is impossible in Git as far as I know.
>>
>
> Git has commit hashes. They play the same role as revision numbers in SVN
> One can checkout the whole commit or an individual file of any commit if
> needed.

That is not what I meant.
The code and build file use the current revision of the file, e.g. @revision.
This is automatically updated when a file is checked out.

>
>
>> Also Git does not support svn:eolstyle as far as I know.
>> This may cause problems with packaging as the EOL type is critical in
>> some files.
>>
>
> The line endings can be configured locally, or in .gitattributes file and
> checked in repository.

So how do you configure some files as native, some as CRLF and some as LF?
This is trivial in SVN, and the settings stay with the file.

>
>
> Best regards,
> Andrey Ponomarev

Re: [Discuss] Migrate JMeter from SVN ASF repo to GIT ASF repo

[Andrey Ponomarev <an...@gmail.com>]

On Tue, Aug 25, 2015 at 3:34 PM, sebb <se...@gmail.com> wrote:

> However there are areas of the build and testing that rely on being
> able to access the revision number of a file.
> That is impossible in Git as far as I know.
>

Git has commit hashes. They play the same role as revision numbers in SVN
One can checkout the whole commit or an individual file of any commit if
needed.



> Also Git does not support svn:eolstyle as far as I know.
> This may cause problems with packaging as the EOL type is critical in
> some files.
>

The line endings can be configured locally, or in .gitattributes file and
checked in repository.



Best regards,
Andrey Ponomarev

Re: [Discuss] Migrate JMeter from SVN ASF repo to GIT ASF repo

[sebb <se...@gmail.com>]

On 25 August 2015 at 11:45, Milamber <mi...@apache.org> wrote:
> Hello,
>
> I would like open a discussion for the opportunity to migrate the JMeter svn
> repo into the git repository of ASF.
>
> Why (IMHO)?
> - because the usage of git seems more easier to make some operations like
> merge or revert a commit

I had to revert some commits in BCEL recently. This uses SVN, but the
process was very easy using Eclipse.
Just select the commit in History and choose "Revert changes from revision xyz"

> - the possibility to merge a pull request from Github is very easy (for
> example, merge a PR to a local branch, tests and if error comment the PR)

It's not that difficult with SVN

> - Allow to create several local branches to test patches from buzgilla, make
> some dev/enhancements on JMeter locally and after the final line code, do a
> PR on Github

Branches in SVN are very cheap.

> - The strong integration between Git and Github and the increasing number of
> developers using github to do a PR on open source projects (and the easy way
> to to that)
>
> Some consequences:
> The release process must change (tag/rc branch and the publishing of the web
> site)
> The website must be updated on the Developers informations

Those are relatively trivial changes.

However there are areas of the build and testing that rely on being
able to access the revision number of a file.
That is impossible in Git as far as I know.

Also Git does not support svn:eolstyle as far as I know.
This may cause problems with packaging as the EOL type is critical in
some files.

> Any thoughts?

I am not saying that it is a non-starter, but it is going to be a lot
of work to get it all working properly.

I suggest setting up a worksheet somewhere (Wiki/Git?) where plans can
be documented and discussed.

> Milamber
>
>

Re: [Discuss] Migrate JMeter from SVN ASF repo to GIT ASF repo

[Hemika Kodikara <he...@gmail.com>]

Hi,

+1 for moving to Git/Github. Much easier when it comes to code reviews due
to PRs.

Regard,
Hemika

On Tue, Aug 25, 2015 at 4:34 PM, Andrey Pokhilko <ap...@ya.ru> wrote:

> Hi,
>
> I support this 100%. I had experience migrating from SVN into Git(HUB)
> with plugins project and Git allows more flexibility and attracts more
> contributors. Handling PATCH files is not as easy as pulling from Git
> repos.
>
> Andrey Pokhilko
>
> On 08/25/2015 01:45 PM, Milamber wrote:
> > Hello,
> >
> > I would like open a discussion for the opportunity to migrate the
> > JMeter svn repo into the git repository of ASF.
> >
> > Why (IMHO)?
> > - because the usage of git seems more easier to make some operations
> > like merge or revert a commit
> > - the possibility to merge a pull request from Github is very easy
> > (for example, merge a PR to a local branch, tests and if error comment
> > the PR)
> > - Allow to create several local branches to test patches from
> > buzgilla, make some dev/enhancements on JMeter locally and after the
> > final line code, do a PR on Github
> > - The strong integration between Git and Github and the increasing
> > number of developers using github to do a PR on open source projects
> > (and the easy way to to that)
> >
> > Some consequences:
> > The release process must change (tag/rc branch and the publishing of
> > the web site)
> > The website must be updated on the Developers informations
> >
> > Any thoughts?
> >
> > Milamber
> >
> >
>
>

Re: [Discuss] Migrate JMeter from SVN ASF repo to GIT ASF repo

[Andrey Pokhilko <ap...@ya.ru>]

Hi,

I support this 100%. I had experience migrating from SVN into Git(HUB)
with plugins project and Git allows more flexibility and attracts more
contributors. Handling PATCH files is not as easy as pulling from Git repos.

Andrey Pokhilko

On 08/25/2015 01:45 PM, Milamber wrote:
> Hello,
>
> I would like open a discussion for the opportunity to migrate the
> JMeter svn repo into the git repository of ASF.
>
> Why (IMHO)?
> - because the usage of git seems more easier to make some operations
> like merge or revert a commit
> - the possibility to merge a pull request from Github is very easy
> (for example, merge a PR to a local branch, tests and if error comment
> the PR)
> - Allow to create several local branches to test patches from
> buzgilla, make some dev/enhancements on JMeter locally and after the
> final line code, do a PR on Github
> - The strong integration between Git and Github and the increasing
> number of developers using github to do a PR on open source projects
> (and the easy way to to that)
>
> Some consequences:
> The release process must change (tag/rc branch and the publishing of
> the web site)
> The website must be updated on the Developers informations
>
> Any thoughts?
>
> Milamber
>
>