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

Re: Best Practices question

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-10-09 17:16:41 CEST

pll@lanminds.com writes:

> $ mkdir /spare/svn
> $ svnadmin create /spare/svn/projA
> $ svnadmin create /spare/svn/projB
> $ svnadmin create /spare/svn/projC

This creates 3 independent repositories. Each project has its own
repository.

> $ svnadmin create /spare/svn
> $ svn mkdir file:///spare/svn/projA
> $ svn mkdir file:///spare/svn/projB
> $ svn mkdir file:///spare/svn/projC

This creates three project subdirectories within a single repository.

> Could someone kindly explain to me what the implications of the above
> actions are, and maybe why I would choose one over the other? Is it
> possible you might want to do the first in some circumstances, but
> the second in others?

Man oh man, we need to make this a FAQ, or put it in the handbook.
People keep asking this. :-)

   * In the second case, code can easily be copied or moved around
     between projects, and the history is preserved. ('svn cp/mv'
     currently only works within a single repository.)

   * Because revision numbers are repository-wide, a commit to any
     project in the 2nd case causes a global revision bump. So it
     might seem a bit odd if somebody has 'projB' checked out, notices
     that 10 revisions have happened, but projB hasn't changed at
     all. Not a big deal, really. Just a little weird at first.
     This already happens to svn, everytime people commit to
     rapidsvn. :-)

   * The first case might be easier to secure; it's easier to insulate
     projects from each other (in terms of users and permissions)
     using Apache's access control. In the 2nd case, you'll need a
     fancy hook script in the repository that distinguishes projects
     ("is this user allowed to commit to this particular subdir?") Of
     course, we already have such a script, ready for you to use.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 9 17:18:37 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.