Hi guys,
you can use a small script to extract the latest "global" revision number; for
SVN, use svn info:
svn info | grep "Revision:"
Revision: 841
$ svn info | grep "Revision:" Revision: 841
For git, you can use the following:
$ git rev-parse --short HEAD
97d20f5
Cheers,
Christian
Christian,
You're correct, using the $Revision$ tag is the comment way to handle
this in svn.
The problem is that this will embed the latest version number where
that particular file changed.
What we want here is the latest revision where any file changed.
Cheers,
Lane
On Thu, Sep 29, 2011 at
I believe a common way to achieve this in svn is to put a $Revision$ tag
somewhere in the file and set the keywords property on the file so svn modifies
the tag appropriately:
http://svnbook.red-bean.com/en/1.4/svn.advanced.props.special.keywords.html
Git doesn't seem to do that. This page has a
This info is available for svn by calling svnversion. One way to embed
this would be as follows:
In the Makefile, add a line like this:
export SVN_VERSION:=$(shell svnversion)
That will set an environment variable with the svn version number. You
should be able to then use this in some sort of i
I know there's a way to put in the svn revision number. Not sure about git.
On Thu, Sep 29, 2011 at 8:05 AM, Hieu Hoang wrote:
> it seems like squishing everything into a bin directory is a good idea
> for people who want to set their PATH variable to it.
>
> it would be useful to do
> moses -
it seems like squishing everything into a bin directory is a good idea
for people who want to set their PATH variable to it.
it would be useful to do
moses --version
train-model.perl --version
and see when or which svn/git version it was built on. Didn't think it
was possible but you mig
On 28.09.2011, at 15:08, Joerg Tiedemann wrote:
> You would probably get a lot of problems when throwing everything into
> one bin-directory. There are, for example, two 'score' binaries (one
> for phrase scoring and one for lexical reordering).
Wouldn't it be better to address this by giving mo
Hi,
just a comment: EMS (experiment.perl) is re-running steps for which the
script/binary has changed. So if you check out an update out of SVN, it will
notice that update. The timestamp is stored in *INFO files, so you could
(if you knew when you updated your versions) backtrack to the correspond
On Wed, Sep 28, 2011 at 5:55 AM, Barry Haddow
wrote:
> Hi
>
> So it looks like a date-stamped release folder is not popular. It would be
> possible to have a version stamp inserted into the binaries and scripts and
> have this read by ems - would this be useful?
Yes, it would be nice to be able t
You would probably get a lot of problems when throwing everything into
one bin-directory. There are, for example, two 'score' binaries (one
for phrase scoring and one for lexical reordering). But it would be
nice if everything executable ends up in appropriate sub-directories
of one common bin dire
Hi
So it looks like a date-stamped release folder is not popular. It would be
possible to have a version stamp inserted into the binaries and scripts and
have this read by ems - would this be useful?
And would a 'make install' be of any use? It would mean that anyone who wanted
a date-stamped
I like your idea of a VERSION.txt file. Maybe containing also the
configure line.
By the way, there is already a make install which is configurable with
"configure --prefix=..." ; I dont understand if you want more than
this.
Raphael
2011/9/27 Lane Schwartz :
> I would like to see a true make i
I concur. I would prefer not to have a date-stamped directory. I'd like
to be able to in theory check out the repository, build, and run a given
EMS config file without having to modify the config file with the new
date-stamped directory. Knowing which version you're running for which
experimen
I would like to see a true make install option. I don't care what the
default location is, as long as it's configurable.
At the least, I would prefer to see the binaries (and preferably
scripts, too) installed to a bin directory within the moses dir
instead of being spread throughout the source di
I'd go with Ondrej and avoid any release procedure and run everything
in-situ. We can debug and commit scripts easier.
Or have a very simple release that moves all executables and scripts into a
bin directory. If the user wants to move/rename, it's their choice
On 27 September 2011 16:30, Barry H
isn't this what version control is supposed to fix?
Miles
On 27 September 2011 10:30, Barry Haddow wrote:
> Hi
>
> I think it's useful to have a date-stamped release directory, so that you can
> work on the code and have experiments running, but keep tracking of which
> version was used in which
Hi
I think it's useful to have a date-stamped release directory, so that you can
work on the code and have experiments running, but keep tracking of which
version was used in which experiment. Many people at Edinburgh make a copy of
the moses binary with the svn version number as suffix on the
17 matches
Mail list logo
