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 16:06:57 GMT
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 <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