You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Anders Hanson <an...@speedo.nu> on 2002/05/02 20:48:50 UTC
Multiple projects in one repository!
Hi,
I've followed this mailinglist for a while and i can say that Subversion
looks
promising!
Now too my question, will subversion support multiple projects in the same
repository?
At my work we are building several applications that share a set of common
libraries.
Currently we are using CVS and have one repository with every library as a
own module.
The big drawback with CVS is the lack of versioned directories, and is this
field subversion
looks very promising, but if we can't have multiple modules in one
repository we have to
stay with CVS.
Another thing is, will the tag and branching "clone" be hidden from the user
as commands.
The way it is now looks confusing for me and my coworkers. Having a separate
dir for every
tag and branch will make the repository overflow with directories. We are
creating atleast
one tag a week and branching every month.
/Anders Hanson
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Multiple projects in one repository!
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Alan Langford <ja...@ambitonline.com> writes:
> >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.
>
> monotonically increasing.
I knew someone was going to answer that question :-).
Thanks!,
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Multiple projects in one repository!
Posted by Alan Langford <ja...@ambitonline.com>.
At 2002/05/02 18:17 -0500, Karl Fogel wrote:
>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.
monotonically increasing.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Multiple projects in one repository!
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Karl Fogel <kf...@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
Re: Multiple projects in one repository!
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Alexis Huxley <ah...@gmx.net> writes:
> 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?
There doesn't have to be any relationship between revision numbers and
release numbers. In most projects I've worked on, there isn't.
> 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.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Multiple projects in one repository! and Re: 'stamping' a la RCS '$Header$'?
Posted by Alexis Huxley <ah...@gmx.net>.
Ben wrote:
> > 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.
Karl wrote:
> $Id$ ===> "$Id http://some.url/blah/blah/andsoforth @ 1661"
Yes, those two tie up very nicely: a release id maps to a [sub]directory
of the repository together with one of the (possibly multiple) repository
revisions in which the files were in a particular state; the first
revision would seem the logical one, because then ...
Russ wrote:
> > and not include Author and Date?
... *that* would make more sense. And definitely - for example in
versioned web pages, - it is nice to see that information in the small
print.
> Please include the date; that's the most useful information in all of $Id$
> for someone looking at the file outside of a version control environment.
>
> I don't see any need for the URL either. The RCS version doesn't include
> it the full path, just the file name.
Yes, it does. It depends whether you use '$Header$' or '$Id$'. I can't
remember which way round it is, but one gives you the full path and the
other one doesn't.
Alexis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Multiple projects in one repository!
Posted by Ben Collins-Sussman <su...@collab.net>.
Alexis Huxley <ah...@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
Re: Multiple projects in one repository!
Posted by Ben Collins-Sussman <su...@collab.net>.
"Anders Hanson" <an...@speedo.nu> writes:
> I know that Subversion doesn't care about the directory structure :)
> What I meant was that it whould be nice if it was possible to have a
> separate revision for each project.
Sorry, we don't have per-directory or per-file revisions. A revision
is global to the repository. Changing that means reworking the
fundamental design of the svn repository, tossing 2 years of work, and
starting from scratch. Not going to happen. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: RE: Multiple projects in one repository!
Posted by Bill Tutt <ra...@lyra.org>.
You know, the revision number that's attached to the repository as a
whole is meaningless from a user's perspective. It's an internal
mechanism that accomplishes the goal of the underlying schema design. It
just so happens to be exposed so that the user's interface can sometimes
be a little more convenient to communicate numbers than obnoxious
date/time strings.
Repository revision number is only relevant to the repository, and user
convenience. It has NO impact on any other factor of what you store in
the repository. One repository has one revision number. This isn't
likely to change. EVER. If it did, it would just make the schema
unnecessarily complicated. If you don't like using the same revision
number system for more than one project, either have more than one
repository, or use date/time strings as the way to reference your
project.
Repository revision number bumps aren't nearly useful enough to be an
accurate indication of the real rate of change of a given code base.
There are other more complicated ways to get a much better picture of a
code base's rate of change.
Additionally, distributed replication systems commonly require a global
repository revision number to indicate distinct points in time that
contained a particular state, so the fact that Subversion has such a
concept makes distributed repository replication easier to add on later.
Bill
----
Do you want a dangerous fugitive staying in your flat?
No.
Well, don't upset him and he'll be a nice fugitive staying in your flat.
> -----Original Message-----
> From: Anders Hanson [mailto:anders.hanson@speedo.nu]
> Sent: Friday, May 03, 2002 9:08 AM
> To: dev@subversion.tigris.org
> Subject: RE: Multiple projects in one repository!
>
>
> I know that Subversion doesn't care about the directory structure :)
> What I meant was that it whould be nice if it was possible to have a
> separate revision for each project. Right now you have to have one
> repository for each project. Like i wrote in my first mail about this
> when you're building products that are built of multible shared libs
> it's not fun to have one repository for each library.
>
> Application 1 uses library 1, 2 and 3
> Application 2 uses libraray 1, 3 and 4
> Application 3 uses libraray 1
>
> It whould be nice if each library could be a separate "module" in the
> repository, with it's own revision number, that is only bumped when
> checking in that module.
>
> /Anders
>
> -----Original Message-----
> From: sussman@collab.net [mailto:sussman@collab.net]
> Sent: den 3 maj 2002 17:51
> To: Anders Hanson
> Cc: dev@subversion.tigris.org
> Subject: Re: Multiple projects in one repository!
>
>
> "Anders Hanson" <an...@speedo.nu> writes:
>
> > If it's possible it whould be nice to have a possibility to
> > have multiple project's in one repository, and have on revision
> > number for every project. Mostly to get rid of all the trunk/
> > tags/ and branch/ directories (one for each proj) and instead
> > have something like this
> >
> > repos/trunk/
> > proj1/
> > proj2/
> > proj3
> > repos/tags/
> > proj1/
> > 0.10
> > repos/branches/
> > proj2/
> > 0.1
> >
> > instead of this
> >
> > proj1/trunk/
> > src/
> > include/
> > tags/
> > 0.10
> >
> > proj2/trunk/
> > src/
> > include/
> > branches/
> > 0.1
>
> You can lay your repository out however you want. Subversion doesn't
> care.
>
> Because subversion's own repository has only one project, we chose the
> latter layout. But if you want to put multiple projects in your
> repository, then the former layout makes more sense, certainly.
>
> Subversion doesn't enforce any structure at all. You can lay out your
> directories however you want. Or rearrange them later if you change
> your mind.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Multiple projects in one repository!
Posted by Anders Hanson <an...@speedo.nu>.
I know that Subversion doesn't care about the directory structure :)
What I meant was that it whould be nice if it was possible to have a
separate revision for each project. Right now you have to have one
repository for each project. Like i wrote in my first mail about this
when you're building products that are built of multible shared libs
it's not fun to have one repository for each library.
Application 1 uses library 1, 2 and 3
Application 2 uses libraray 1, 3 and 4
Application 3 uses libraray 1
It whould be nice if each library could be a separate "module" in the
repository, with it's own revision number, that is only bumped when
checking in that module.
/Anders
-----Original Message-----
From: sussman@collab.net [mailto:sussman@collab.net]
Sent: den 3 maj 2002 17:51
To: Anders Hanson
Cc: dev@subversion.tigris.org
Subject: Re: Multiple projects in one repository!
"Anders Hanson" <an...@speedo.nu> writes:
> If it's possible it whould be nice to have a possibility to
> have multiple project's in one repository, and have on revision
> number for every project. Mostly to get rid of all the trunk/
> tags/ and branch/ directories (one for each proj) and instead
> have something like this
>
> repos/trunk/
> proj1/
> proj2/
> proj3
> repos/tags/
> proj1/
> 0.10
> repos/branches/
> proj2/
> 0.1
>
> instead of this
>
> proj1/trunk/
> src/
> include/
> tags/
> 0.10
>
> proj2/trunk/
> src/
> include/
> branches/
> 0.1
You can lay your repository out however you want. Subversion doesn't
care.
Because subversion's own repository has only one project, we chose the
latter layout. But if you want to put multiple projects in your
repository, then the former layout makes more sense, certainly.
Subversion doesn't enforce any structure at all. You can lay out your
directories however you want. Or rearrange them later if you change
your mind.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Multiple projects in one repository!
Posted by Ben Collins-Sussman <su...@collab.net>.
"Anders Hanson" <an...@speedo.nu> writes:
> If it's possible it whould be nice to have a possibility to
> have multiple project's in one repository, and have on revision
> number for every project. Mostly to get rid of all the trunk/
> tags/ and branch/ directories (one for each proj) and instead
> have something like this
>
> repos/trunk/
> proj1/
> proj2/
> proj3
> repos/tags/
> proj1/
> 0.10
> repos/branches/
> proj2/
> 0.1
>
> instead of this
>
> proj1/trunk/
> src/
> include/
> tags/
> 0.10
>
> proj2/trunk/
> src/
> include/
> branches/
> 0.1
You can lay your repository out however you want. Subversion doesn't
care.
Because subversion's own repository has only one project, we chose the
latter layout. But if you want to put multiple projects in your
repository, then the former layout makes more sense, certainly.
Subversion doesn't enforce any structure at all. You can lay out your
directories however you want. Or rearrange them later if you change
your mind.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Multiple projects in one repository!
Posted by Anders Hanson <an...@speedo.nu>.
If it's possible it whould be nice to have a possibility to
have multiple project's in one repository, and have on revision
number for every project. Mostly to get rid of all the trunk/
tags/ and branch/ directories (one for each proj) and instead
have something like this
repos/trunk/
proj1/
proj2/
proj3
repos/tags/
proj1/
0.10
repos/branches/
proj2/
0.1
instead of this
proj1/trunk/
src/
include/
tags/
0.10
proj2/trunk/
src/
include/
branches/
0.1
I think that most people will feel that the first version
is more logic and stright forward.
If this is possible, why stay with one fixed way of doing
it, instead of making it possible to do it both way?
Take a look at http://cvs.gnome.org/bonsai/rview.cgi?cvsroot=/cvs/gnome
Imagnine if all those projects had been in separate repositories.
I'm not here to bash your design, just trying to help make Subversion
useful for a larger group of ppl :)
/Anders
-----Original Message-----
From: Alexis Huxley [mailto:ahuxley@gmx.net]
Sent: den 2 maj 2002 23:10
To: dev@subversion.tigris.org
Subject: Re: Multiple projects in one repository!
> > Now too my question, will subversion support multiple projects in the
same
> > repository?
>
> 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. :-)
Re: Multiple projects in one repository!
Posted by Alexis Huxley <ah...@gmx.net>.
> > Now too my question, will subversion support multiple projects in the same
> > repository?
>
> 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. :-)
Re: Multiple projects in one repository!
Posted by Ben Collins-Sussman <su...@collab.net>.
"Anders Hanson" <an...@speedo.nu> writes:
> Now too my question, will subversion support multiple projects in the same
> repository?
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. :-)
> Another thing is, will the tag and branching "clone" be hidden from
> the user as commands. The way it is now looks confusing for me and
> my coworkers. Having a separate dir for every tag and branch will
> make the repository overflow with directories. We are creating
> atleast one tag a week and branching every month.
Nope, not hiding anything. Branches and tags are just cheap directory
copies. You clone a directory using the 'svn cp' command.
It's a matter of site-policy to manage the "overflow" of directories.
Tags and branches are just ordinary directories, after all. You can
rearrange them into any structure you want.
By the way: this is not a new idea. Perforce, I'm told, has the same
model.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Multiple projects in one repository!
Posted by "Mark C. Chu-Carroll" <mc...@watson.ibm.com>.
On Thu, 2002-05-02 at 16:48, Anders Hanson wrote:
> Hi,
>
> I've followed this mailinglist for a while and i can say that Subversion
> looks
> promising!
>
> Now too my question, will subversion support multiple projects in the same
> repository?
>
> At my work we are building several applications that share a set of common
> libraries.
> Currently we are using CVS and have one repository with every library as a
> own module.
>
> The big drawback with CVS is the lack of versioned directories, and is this
> field subversion
> looks very promising, but if we can't have multiple modules in one
> repository we have to
> stay with CVS.
Stellation does support multiple projects per repos, including
overlapping projects. I can't imagine that with the link architecture
that the same thing would be any problem for svn.
>
> Another thing is, will the tag and branching "clone" be hidden from the user
> as commands.
> The way it is now looks confusing for me and my coworkers. Having a separate
> dir for every
> tag and branch will make the repository overflow with directories. We are
> creating atleast
> one tag a week and branching every month.
You don't generally directly look at the repository pathnames in a
system like this. It's an internal thing. You access branches by
project/branch/version. And tags are essentially branches with only one
version.
-Mark
>
> /Anders Hanson
--
Mark Craig Chu-Carroll, IBM T.J. Watson Research Center
<mc...@watson.ibm.com>
*** The (recently renamed) Stellation project:
*** http://domino.research.ibm.com/synedra/synedra.nsf
*** GPG Public key available at keyserver.net