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

Re: Rapidly-changing revision number

From: Kenneth Porter <shiva_at_sewingwitch.com>
Date: 2006-10-13 23:34:44 CEST

--On Friday, October 13, 2006 4:51 PM -0400 Frank Gruman
<fgatwork@verizon.net> wrote:

> I think the discussion of the revision as a timestamp is a bit vague. To
> elaborate on it, the timestamp is used to identify the state of the
> repository at virtually any given time. This is where the discussion
> goes on a tangent about creating separate repositories for unrelated
> projects.
> My preference and the way I have my repos set up - each project has it's
> own repository. If I want to do some sort of work/testing/anything to
> one, I don't have to kill the whole development process to do it. From
> the developer perspective, they know that their code is segregated by
> project. They don't know or care that there are one or many repositories.

Setting up projects in their own repositories makes sense if they're
independent. If one project depends on another, or they share a common
library project, then a shared repository insures that changes in the
depended-upon project that break the dependent project can be identified
and rolled back.

Alas, the real world is full of coupling between projects, so one is
tempted to put all projects in one repo. But separate repos tend to be
easier to admin. So it depends on just how much coupling there is between
the projects.

If you've got good interface boundaries that can be represented by a repo
tag, then separate repos are tenable, as changes to the library are
captured in tags and the dependent project can specify the tag(s) that it's
compatible with.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 13 23:36:14 2006

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

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