[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Multiple projects in one repository!

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-05-03 01:17:37 CEST

Karl Fogel <kfogel@newton.ch.collab.net> writes:
> > Talking of release numbers, now that I'm trying to work out how to
> > assign release numbers to my own s/w, I'd like to know how it is done
> > in SVN itself: what does "version 1.0" actually mean? I mean it
> > must really map to repository revision, right? How is the association
> > made? Is it those darn' properties again? ;-)
>
> Nope. Our release numbers have no relation to our revision numbers.

Sorry, I should be clearer:

You will see download tarballs called `svn-rXXXX.tar.gz', where XXXX
is a revision number. We can get away with this because we only have
one project (Subversion itself) in our repository, and also because
these are not particularly important releases, from a publicity
standpoint.

When it comes time to release 1.0, you can bet it will be called
`svn-1.0.tar.gz', though :-). That's what I meant by "no relation".

But even in a repository with multiple projects, its fine to release a
tarball called

   thisproj-rXXXX.tar.gz

and then a month later release

   thisproj-rYYYY.tar.gz

because as long as YYYY is *higher* than XXXX, people know which one's
later and which one's earlier. People don't need a promise that every
integer from (XXXX + 1) to YYYY implies a change to `thisproj'. They
just need to know that some number of changes has occurred (which is
obvious, or the later release wouldn't exist).

There's some mathematical term for this relationship, but I can't
remember what it is. Anyway, the point is it's fine for revision
numbers to serve as release numbers, since they both move in the same
direction, albeit at different rates.

The only problem arises if people think that somerev+N necessarily
represents a change to the project they care about. It might, or it
might not.

Hope that's clearer.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 3 01:16:36 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.