Alexis Huxley <ahuxley@gmx.net> writes:
> > A repository is just a filesystem that changes over time. Subversion
> > has no notion of "projects". If you want to put lots of different
> > projects in your filesystem, that's your choice. The only thing that
> > makes certain directories into "projects" is the fact that you think
> > of them that way. :-)
>
> From the storage point of view, I can see this. But what about the
> 'release' number? You wouldn't want the version number of, say, Emacs,
> to be bumped as a result of a change to another program, say, Mutt, even
> if they're - because the same person is developing both - in the
> same repository, right?
Well, that's a side-effect, yes. It depends on whether that bothers
you or not. If the side-effect bothers you, you'll need to put each
project in a separate repository.
Personally, it doesn't bug me. I think it's too easy to think of a
repository "revision" as some big special number that has something to
do with how advanced your project is. But that's just not necessarily
true. It's just a measure of how many commits have been made to your
repository, whether your repository has one or N projects in it... and
you needn't give it any more weight than that. Your software release
number is whatever you want it to be.
> 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?
Sure, although we'll probably create a 1.0 branch, and keep /trunk
moving forward. So it's better to say that Subversion 1.0 corresponds
to a revision and a *path*, not just a revision.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 2 23:40:54 2002