git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Norbert Preining <preining@logic.at>
To: Johan Herland <johan@herland.net>
Cc: git@vger.kernel.org
Subject: Re: Creating something like increasing revision numbers
Date: Sun, 18 Oct 2009 17:20:54 +0200	[thread overview]
Message-ID: <20091018152054.GA3956@gamma.logic.tuwien.ac.at> (raw)
In-Reply-To: <200910181703.20607.johan@herland.net>

On So, 18 Okt 2009, Johan Herland wrote:
> A global, increasing version number ala SVN is fundamentally impossible in 
> any distributed version control system (like Git).

Yes, agreed. 

The point is that I do not actually need the "distributed" part of git.
I want one central repository and all collaborators commit to that.
Yes, that is subversion, I know.

We have no branches, no tags, nothing of that. Only trunk.

>     $ git describe
>     v1.0.4-14-g2414721
> 
> where the "v1.0.4" part is the last tag that the current state is based on, 
> the "14" part is the number of commit between that tag and the current 

So if we have only one tag (initial) then it would count the number
of commits?

And if yes, is it easy to find out at which commit a file has been changed
last time (svn status -v).

I have read a lot on the net about the impossibility, and I agree that
in a distributed setting it does not work.

And in fact we would not even have revision numbers on our local
git repositories. Only one (the master checkout from which our 
distribution server is updated) needs to have some commit numbers.

THe reason is that we use that as serial number for packages. One packages
is roughly on package from CTAN (Comprehensive TeX Archive Network, 
like CPAN), and we want to make sure that if that is updated on CTAN
and we import it into our system, the next time we create a TeX Live
package for it (that will be served to quite a lot of users) we have
a new version number.

We first thought about using the version number as provided by authors,
but that is completely useless, because there are tooo many authors
of packages on CTAN where the version numbers are in no way increasing ;-)
So we settled for the max of all the last changed revision number of
the contained files, whcih is guaranteed to increase.

As a lat resort I will try to use git-svn ...

Again, thanks a lot and all the best

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining                                        Associate Professor
JAIST Japan Advanced Institute of Science and Technology   preining@jaist.ac.jp
Vienna University of Technology                               preining@logic.at
Debian Developer (Debian TeX Task Force)                    preining@debian.org
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
QUOYNESS (n.)
The hatefulness of words like 'relionus' and 'easiephit'.
			--- Douglas Adams, The Meaning of Liff

  reply	other threads:[~2009-10-18 15:21 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-18 14:41 Creating something like increasing revision numbers Norbert Preining
2009-10-18 15:03 ` Johan Herland
2009-10-18 15:20   ` Norbert Preining [this message]
2009-10-18 17:23     ` Johan Herland
2009-10-18 18:16       ` alexandrul
2009-10-19  1:15       ` Nicolas Pitre
2009-10-18 22:47     ` Junio C Hamano
2009-10-19  0:48       ` Norbert Preining
2009-10-18 15:29 ` alexandrul
2009-10-18 15:37   ` demerphq
2009-10-18 15:45     ` Norbert Preining
2009-10-18 16:16       ` demerphq
2009-10-18 16:35         ` alexandrul
2009-10-18 15:37 ` Jon Smirl
2009-10-18 21:43 ` Daniel Barkalow
2009-10-19  0:44   ` Norbert Preining
2009-10-19  1:16     ` Daniel Barkalow
2009-10-19  1:33       ` Norbert Preining
2009-10-19  2:41         ` Daniel Barkalow
2009-10-19  1:34     ` Nicolas Pitre
2009-10-19  1:42       ` Norbert Preining
2009-10-19  6:21     ` Johannes Sixt
2009-10-21  7:47     ` David Aguilar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091018152054.GA3956@gamma.logic.tuwien.ac.at \
    --to=preining@logic.at \
    --cc=git@vger.kernel.org \
    --cc=johan@herland.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).