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

Re: Version handling

From: A.T.Hofkamp <a.t.hofkamp_at_tue.nl>
Date: 2005-11-14 18:14:54 CET

Datatal AB - Jonas Gauffin wrote:
> Got another question. We break the codebase at every release to be able
> to support current version + 2 old.
> This means that we need to have 3 different copies of the source code in
> subversion, I would like to create a structure like the following:
> contactcenter\1.0
> contactcenter\1.1
> contactcenter\1.2
> What is the best way to do it?

As Paul Koning already stated, with tags or branches.

SVN is designed to handle this situation for you.

> I was thinking about creating a repos called contactcenter and then just

Why not in the same repos as where your development takes place (aka the trunk)?
Then it is easy to create new version, and to merge bugfixes between different
version and/or the dev trunk.

> create three different folders in it. But that would increase version
> number each time I do a change in any of the versions, right?

You mean the repository revision number? ('version number' is commonly used
for `real' versions like your 1.0 or 1.1 above, `revision numbers' is normally
used for the smaller changes, like the modification count of the SVN repo.)

Yes it does. But that is not bad, I consider it an internal number used by svn
to uniquely number all modifications. There is no need to publish this number,
you publish versions by creating a tag/branch like you did above.

> My second thought was to create a regular folder named "contactcenter"
> and in that folder create 3 different repos. But when doing that I get
> the following error when browsing it:

Sorry, no idea how to configure Apache for this.

> How I did it:
> First try was to get it running with one repos called contactcenter,
> /subversion/public/contactcenter, which went ok (worked in the browser).
> Next I renamed it to 1.1 and created a regular dir called contactcenter.
> /subversion/public/contactcenter <-- regular dir
> /subversion/public/1.1 <-- contactcenter repos renamed to 1.1
> After that I moved the 1.1 repos into the contactcenter dir.
> /subversion/public/contactcenter/1.1 <--- repos now in the contactcenter
> folder
> Suggestions? =)

I would use different repos only for projects that are not related and use 1
repo otherwise. The big advantage of having stuff in 1 repo is that it is very
easy to merge/move/copy/etc code from one point to the other.
Between repo's it is much harder.
Also, if projects share a common history which you want to have available (and
if not today, maybe tomorrow?), use one repo (remember, a repo not only
contains the current state but also the history of the project).

To explain this more, consider what happens when you have different repos for
each version.
If you move from (for example) version 1.2 to 1.3 and you have different repos
for each version, then you have to create a new repo for version 1.3. Upon
initialization of the 1.3 repo, you'd have to think about what you want to do
with the history of 1.2: copy it to 1.3 or not.
* If you do, then effectively you accumulate the history of the entire project
in the repo of the latest version (that is, all previous versions are a subset
of the latest version, and thus all repo's of the previous versions are then
also a subset of the latest repo). In other words, you are wasting disk and
backup space due to making copies of subsets of the same data.
* If you don't, then you cannot go back to before the birth of the version,
you'd have to switch repo for doing that. That becomes quite unmanagable when
you want to find out how a change occurred several versions back.

To me, it sounds like you'd be much happier if you use one repo for the project.

Just my euro 0.02

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 14 18:18:24 2005

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.