jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: [Discuss] Migrate JMeter from SVN ASF repo to GIT ASF repo
Date Sat, 17 Oct 2015 13:37:19 GMT
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 <sebbaz@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 <sebbaz@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message