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 < [email protected]> wrote: > > > Am 17. Oktober 2015 15:37:19 MESZ, schrieb Philippe Mouawad < > [email protected]>: > >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 > ><[email protected] > >> 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 < > >> [email protected]> wrote: > >> > >>> On Tue, Aug 25, 2015 at 6:21 PM, sebb <[email protected]> wrote: > >>> > >>> > On 25 August 2015 at 17:06, Andrey Ponomarev < > >>> [email protected]> > >>> > wrote: > >>> > > On Tue, Aug 25, 2015 at 4:25 PM, sebb <[email protected]> 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.
