Re: tarballs again

2012/11/21 James K. Lowden <[email protected]>:
> On Wed, 21 Nov 2012 10:05:23 -0500
> Ken Collins <[email protected]> wrote:
>
>> Awesome! When will the build system update these files and to which
>> version numbers? ftp://ftp.astron.com/pub/freetds/
>
> The overnight system generates new tarballs at 3:00 AM Eastern Time
> whenever the repository changes.  The tarball generation process has
> been broken for a while because your humble maintainer hasn't been able
> to warm up to git.  I just modified the script again in the
> undiminished hope of getting it right this time.
>
> The version number is derived from "git describe": the branch name, and
> the number of commits to that branch (in the Gitorious repository).
> Use of that sequence number makes it a difficult to reconcile the
> tarball's name with a particular revision in the git repository, but
> does produce a number that grows over time, providing a hint to users
> and packagers which version comes after which other.  Together with the
> date, it should be possible to know where a tarball came from; to be
> absolutely certain, one could clone the repository and check out the
> appropriate revision.
>
> Two tarballs are generated: one for the current development version
> (master) and one for the current release (today, 0.91).  This permits
> us to produce "patch releases" without further work when defects are
> found in the current release.
>
> The git command sequence for each working directory is now:
>
>         git clean
>         git reset --hard origin/$(BRANCH)
>         git clean
>         git pull
>
> Previously, git reset was always using master, ruining the patch
> releases.  I added the last command, git pull, because the development
> tarball wasn't picking up subsequent updates.
>
> The development tarball generation is the one you're interested in
> because that's the one to which Frediano added the -D option.
>

Thanks James.

> I see advantages to git, but not for someone like me who uses it only
> every now and again.  The process of cleaning a working copy of all
> non-repository files and bringing it into sync with a known revision is
> certainly harder than it was with CVS and Subversion.
>

Well... comparing svn/cvs with git is from many aspects not that fair.
However after having used HG I have to say that the command line
interface of it is much easier and consistent than git.

Frediano