Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2003:
[Freeciv-Dev] Re: (PR#2479) Change version string of development version
Home

[Freeciv-Dev] Re: (PR#2479) Change version string of development version

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#2479) Change version string of development versions
From: "Raimar Falke via RT" <rt@xxxxxxxxxxxxxx>
Date: Wed, 29 Jan 2003 12:20:55 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Wed, Jan 29, 2003 at 10:17:48AM -0800, Paul Zastoupil via RT wrote:
> On Wed, Jan 29, 2003 at 09:45:45AM -0800, Raimar Falke via RT wrote:
> > On Wed, Jan 29, 2003 at 09:00:46AM -0800, Jason Short via RT wrote:
> > > Secondly, it will require a commit to this file every time any other 
> > > file is committed.  This may be done by a script, but having a script 
> > > that actually makes changes to the code is dangerous.
> > 
> > The script only commits the file with -f and CVS itself will update
> > the $Id...$ value.
> > 
> > > Thirdly, it won't actually give foolproof results.  If you "cvs up -A" 
> > > or "cvs up -D ..." from the toplevel directory, you're fine.  But if you 
> > > apply a patch or update only part of a repository, your datestamp will 
> > > be misleading.  So the end result is that it will work for the daily 
> > > snapshots, but not too well for any self-compiled CVS versions.
> > 
> > I agree.
> > 
> > > The goal is to know what code someone is using when they report a bug. 
> > 
> > IMHO the goal is more to get a more accurate label for the meta
> > server. Bugs reports against CVS alwas have to happen against a clean
> > HEAD version of CVS.
> 
> But isn't the question "which" clean version of HEAD?

Add a "current".

> A perfect solution would seem to need a timestamp on the version.

We can do the mapping of master file revision to time without
problems.

> But we don't have that many commits...

But only commits change features (of the CVS version). We can't do
much for local changes. The only solution I know of for this was the
suggestion of using the number of capabilities.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "I do feel kind of sorry for Microsoft. Their attornies and marketing
  force must have tons of ulcers trying to figure out how to beat (not
  just co-exist with) a product that has no clearly defined (read
  suable) human owner, and that changes on an hourly basis like the
  sea changes the layout of the sand on a beach. Severely tough to
  fight something like that."
    -- David D.W. Downey at linux-kernel




[Prev in Thread] Current Thread [Next in Thread]