jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Ponomarev <andrey.ponoma...@gmail.com>
Subject Re: [Discuss] Migrate JMeter from SVN ASF repo to GIT ASF repo
Date Tue, 25 Aug 2015 18:19:02 GMT
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

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