jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <felix.schumac...@internetallee.de>
Subject Re: [Discuss] Migrate JMeter from SVN ASF repo to GIT ASF repo
Date Sat, 17 Oct 2015 15:47:52 GMT


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


Mime
View raw message