Mike Mason's a little bewildered, but blogging anyway...
Mike is currently…
trying to be Canadian
[ subversion book ]
obligatory book plug
[ syndicate ]
rss 2.0 feed for boy meets world
[ contact ]
drop me a line
[ about ]
this is mike mason's weblog
[ eskimoman.net ]
original web pages
Thu, 09 Sep 2004
This is an archived blog post. I've switched to using WordPress as my blogging software and have not migrated all my old posts. I believe strongly in not letting an old link die, so this page continues to work. Please do visit mikemason.ca/blog to read newer posts.
Subversion: One Repository or Two?
Back to my favourite subject – Subversion source control. A colleage of mine was upgrading from CVS to Subversion, and asked me about single verses multiple repositories. He had different CVS modules corresponding to projects he was working on, and different expectations for the amount he’d access those repositories. Some of his projects were “old” in that he didn’t access them very often, and some were very “live” – he needed a copy of the live ones on his laptop, his home workstation, and on his portable hard drive. He was worried about sync times – updating all those old projects can take quite a while with CVS, hence the separation into different modules.
The question is, do multiple CVS modules equate to multiple repositories with Subversion? Not directly – a Subversion repository probably corresponds to a CVS root, and a CVS module to just a plain old directory within Subversion. It would be easy to have a “live” and “archive” directory in a single Subversion repository, but what about update times?
I thought overall he should try putting everything in a single repository, and see how well it worked. Subversion is a step up from CVS, so update times are pretty fast. Subversion also provides a number of tools so that you can split paths from a repository and load them into another repository – even if it doesn’t work out with a single repository we can change our minds later. The Subversion tool to achieve this is called svndumpfilter. It turns out that in my colleague’s case, the single repository approach worked out fine.
There are times when using multiple repositories is appropriate. Each new repository is something extra to administer, but this overhead also gives flexibility. If you need to take down a repository for maintenance (unlikely when using Subversion but still plausible), you can take down a single repository without affecting others. If you’ve got a project that is outgrowing the server it’s on, it might make sense to split the repository in two so you can add more hardware.
In most cases though, I’d recommend using a single repository until you’ve got a concrete problem that will be solved by using multiple repositories.
Posted 01:09, 09 Sep 2004.
[ permalink ]
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 |
[ tim bacon ]
musings of an xp coach
[ ian bourke ]
enhancing core competencies since 1976
[ martin fowler ]
a cross between a blog and a wiki
[ alan francis ]
agile != good
[ paul hammant ]
part of the problem…
[ darren hobbs ]
the blog formerly known as pushing the envelope
[ mike roberts ]
on life and technology
[ chris stevenson ]
skizz-biz
[ joe walnes ]
joe's new jelly
[ rob baillie ]
oracle
Registered plugins: SmartyPants, antispam, bloglinks (v0.2), calendar (v0+6i), pluginfo (v1.0), and userstatus (v0.1)
This work is licensed under a
Creative Commons License.