File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Other Open Source Projects and the fly likes Organizing multiple projects in SVN Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Products » Other Open Source Projects
Bookmark "Organizing multiple projects in SVN" Watch "Organizing multiple projects in SVN" New topic
Author

Organizing multiple projects in SVN

Frank Harper
Greenhorn

Joined: May 27, 2004
Posts: 5
Hi Jeff,

If you're working on multiple projects what are the advantages/disadvantages of having one repository or multiple repositories?

Thanks,
Frank
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
This question may be asked also for CVS, but I canno see either and advantage or a disadvantage for this. Usually companies keep all the sources in the same repository for the ease of usage (not requiring to change the repository info in the client, everytime you change a project).

--
./pope
[the_mindstorm]


blog - InfoQ.com
Craig Demyanovich
Ranch Hand

Joined: Sep 25, 2000
Posts: 173
Subversion repositories have a global revision number. It changes whenever *any* project in the repository changes. If people are uncomfortable with seeing the repository revision number change even though their project hasn't changed, then you could instead have one project per repository. Another idea is to put only related projects in the same repository, perhaps giving you a few repositories each with a few related projects.

Now, the advantage of a single repository is that security and maintenance (e.g., backups) need be configured only once. The disadvantage of many repositories, then, is that these steps may be performed many times.

You just need to find a balance between maintenance and what feels comfortable for your development team(s).

Craig
Jeff Machols
author
Ranch Hand

Joined: Sep 07, 2004
Posts: 43
This actually gets convered in detail in the book. You should seperate based on administration and release methods. Multiple projects in a repo share the version number (should not be a big deal), hook/trigger scipts and DB configs. If you setup multiple projects roots inside one repo, you can have different branching and tagging methods since Subversion just sees them as different directories. Also, if you have different admins for projects, you may need to seperate.

Where possible, I would suggest having the fewest number of repositories possible and create different project roots. By using an Apache authorization module, you can create ACL's inside the repository to allow different users different permissions based on the directory


Author of <a href="http://www.amazon.com/exec/obidos/ASIN/1932394362/ref=jranch-20" target="_blank" rel="nofollow">Subversion in Action</a>
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995

Multiple projects in a repo share the version number [...]


Let me understand this: if I import 2 different projects to the same repository it would mean that commiting in one of them will increase the version no in the 2nd (unrelated) project? This is quite odd. Does it mean that Apache is using tens of repos?

--
./pope
[the_mindstorm]
Craig Demyanovich
Ranch Hand

Joined: Sep 25, 2000
Posts: 173
My understanding is that "projects," groups of related files and directories, don't have their own revision numbers. Rather, the repository as a whole has a revision number. Any change in the repository increments the revision number.

For example, a new repository is a revision 0. Importing ProjectA increments repository revision number to 1. Importing ProjectB increments repository revision number to 2. Committing a change to ProjectA incrments repository revision number to 3. So, although ProjectB hasn't changed the repository revision number has. This confuses some people. They can choose to investigate it and adjust to it, or they can choose to do something like use one repository for each project.

Hope that helps,
Craig
Jeff Machols
author
Ranch Hand

Joined: Sep 07, 2004
Posts: 43
That is correct, version number is based on the repository. Actually, Apache only has one repo. Now if you do a log on a file (or directory/project root) you will only see the revisions that changed.

so file.c would look something like this

r1 initial revision

r2 changed something

r8 changed something else

This means file.c changed in revision 1,2 and 8 of the repository. If you checkout revision 5 of the repository, you get the "version 2" of file.c

This is different and takes some getting used to, but in the end I think it helps.
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
this will be added to my dislike of pure numbers versioning.

--
./pope
[the_mindstorm]
Jeff Machols
author
Ranch Hand

Joined: Sep 07, 2004
Posts: 43
I felt the same way at first. Take a look at section 1.3, hopefully that will make you feel a little better

http://www.manning-source.com/books/machols/machols_chp1.pdf
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
Jeff I do not dislike the idea behind having the whole project versioned the same. Rather I consider this very nice. What I don't like is having 2 different projects numbered as the repository revision. I guess the main notion for subversion is not project but repository. If i place projects inside the same repo than they will be only directories. I think this must be very well underlined. I am for example maintaining locally to absolutely independent projects. I would like to see that project A is now at version 50 and B is only at version 11.

This brings me to another question: after having a repo with the above 2 projects is there a way to separate them into different repos and having also the history?

--
./pope
[the_mindstorm]
Jeff Machols
author
Ranch Hand

Joined: Sep 07, 2004
Posts: 43
You can "link" repositories inside each other with the svn switch command. So let's say your working copy looked like this from repo1

/working/repo1/gui_program/trunk

This would point to repo1. Now you could create a new diretcory and use the switch command to point it to repo2

/working/repo1/db_program/...

Even though db_program is repo2 is will look like it is in repo1, but remain seperate. The only thing is if you look at history as a whole, you might see duplicate or numbers out of sequence.
Guy Allard
Ranch Hand

Joined: Nov 24, 2000
Posts: 776
I have recently been playing with SVN at home, am very familiar with CVS.

I think you just have to adjust your thinking about tags and branches a little to use SVN effectively - the version numbering doesn't really matter - doesn't with CVS either if you tag/branch reasonably.

Multiple repositories have more to do with backups/restores/administration seems like to me.

Just my current thoughts ......

Guy
Jeff Machols
author
Ranch Hand

Joined: Sep 07, 2004
Posts: 43
Guy - that is the basic idea, revision numbers should not matter. Like any change in a paradigm, it is almost easier for someone new to come in than a person with experience in the traditional way. It took me a long time to accept this.

One of the nice things about the simplicity of branches and tags is the flexibility. You can pretty much use any strategy you want and the tool can conform.
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
Jeff I do not much agree. The revision numbers count. I wouldn't use a revision system that uses *no* numbering scheme, but offering exactly the same functionality.
I am probably not getting the rationale behind having *only* repository version and not *project* versions, but for the moment this seems just coming as a tech decision for ease of development.

--
./pope
[the_mindstorm]
Philip Shanks
Ranch Hand

Joined: Oct 15, 2002
Posts: 189
At first I too was a bit disturbed at the revision numbering scheme. But I find that I am looking at versioning log comments much more than integers because there is so much more information there. "Added documentation for foo.c" is much more meaningful for me than "23".


Philip Shanks, SCJP - Castro Valley, CA
My boss never outsources or has lay-offs, and He's always hiring. I work for Jesus! Prepare your resume!
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Organizing multiple projects in SVN
 
Similar Threads
Should I resign if I felt depress with messy code ?
DWR Security Exception
importing multiple projects into eclipse through command line
Eclipse project -> Jar ?
Third party libraries and WSAD 5.1.0