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, 03 Oct 2015 11:49:37 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message