Hi Brad,
> We are finally about to implement Subversion here at work, moving from
> PVCS,
> and I'd like to get a feel for what folks think are some of the more
> useful
> practices you've seen, and why you think they are useful. The two main
> subject areas I'm interested in are layout and hook scripts.
>
> WRT layout, have you found that having everything in one repository has
> worked out for you, or have multiple repositories worked better. We
> have a
> number of projects ongoing, which are related from a business
> standpoint,
> but not so much from a software standpoint. However, they do share
> some
> library code. The network manager doesn't seem to have a problem with
> multiple repositories, just as long as it doesn't get ridiculous. :)
>
> On the other subject, hook scripts, we've identified a few things that
> we
> want to do, such as preventing commits with blank or non-existent log
> messages, preventing commits where certain properties aren't set, such
> as
> line-style, preventing commits when certain properties *are* set, such
> as
> keyword expansion, preventing commits to tags, etc.
>
> What types of things that can be done with hook scripts have you found
> to be
> beneficial, or useless for that matter?
If no code gets copied back and forth between projects, then you're
probably better off with one repository per project. If a project uses
a library that's stored in another repository, you can use the
svn:externals property to automatically bring the library code into
working copies of the project.
On the other hand, if you frequently copy a file from one project over
to a different project, then you might want to place all of your
projects into a single repository (or at least group the projects where
copying is likely to occur. That way you will be able to preserve the
file's history when you perform the copy.
As far as hook scripts go, one thing you might want to consider is
integration with your issue tracking system. If you use an issue
tracking system that can be controlled remotely, you may want to have
commits include an issue number in their log message (in an easily
parseable format), as well as possibly a tag that identifies how the
commit relates to that issue (e.g. does it close the issue? apply
towards the issue? reopen the issue?). That way, you can have commits
automatically linked into your issue tracking system, and don't have to
worry about the issue tracker getting out of date with the repository.
If you don't already have an issue tracker, and want the integration,
you might want to take a look at Trac (http://trac.edgewall.com/). I
use it for my company's projects, and it have found it to be pretty
nice. It provides a issue tracker, along with good Subversion
integration and an integrated wiki. One downside, though, is that it
doesn't have good support for multiple projects. Either you set up
multiple repositories and link them to multiple Trac instances, or you
link a single Trac to a single repository and handle all projects under
a single Trac (which works---that's what we do---but it's not perfect
because Trac doesn't really recognize multiple projects).
Hope that helps,
-Bill
P.S. If you'll excuse a bit of self-promotion, I have a book coming out
in a few weeks that goes into much greater detail on exactly the things
you seem to be interested in. I talk a lot about repository layouts,
hook scripts, and other Subversion--Development Process integration. I
also have some real-world case studies of companies that use Subversion
and how they make it a part of their workflow. Additionally, I think
it wins the prize for Longest Title in a Subversion Book, with the name
"Subversion Version Control : Using the Subversion Version Control
System in Development Projects". It's available for pre-order on
Amazon:
http://www.amazon.com/exec/obidos/tg/detail/-/0131855182/
qid=1113575857/sr=8-1/ref=sr_8_xs_ap_i1_xgl14/002-2989528-2945639?
v=glance&s=books&n=507846
>
> Thanks,
> Brad
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 22 16:54:54 2005