On 6/10/05, Marcus Patino Pan <marcus.patino.pan@securetrading.com> wrote:
>
> I have a few questions about what is the best way to set up a svn controlled
> system.
Since I haven't seen a reply from one of the true svn experts, I'll
try to chip in a bit.
> We currently use CVS on SuSe 9.2 machines, and we have come across some of
> its limitations so are now thinking of switching to subversion.
>
>
>
> The way we use cvs is as follows, we all work on the main trunk and once our
> code is ready we tag it. If any further changes are required we will create
> a branch and use that, this is so all the other developers can continue
> working on the main trunk. Once the branch is fully working we will tag
> that and release it. We would then merge the branch back into the main
> trunk.
>
>
>
> Our main question is, are we going about the whole control versioning in a
> wrong way? The reason we do it this way is as follows:
Hmm. Since I'm a pragmatist in this respect, I'd say the answer at
some level is, "Does it work for your project?" That said, there's a
lot of collected wisdom in the various "best practices" guides out
there (for a start, cf. http://svnbook.red-bean.com/en/1.1/ch04.html
for the Subversion developers' take on common issues), and there are
some basic principles that help you to get the most mileage out of
your version control system:
- Every file version that might be referenced from the outside world
should be in the repository. (Phrased negatively, never release
anything that's not identical to a version in the repo.) The
description you give abouve seems to adhere to this.
- The granularity of commits to the repo should make auditing (and
reversion) easy. This is what motivates the common
one-edit-one-commit rule. The summary above doesn't really address
this, but see below.
- The metadata associated with each committed change should make
understanding it, and finding it in the future, easier. The most
important factor here in svn and cvs is a good log message. At the
least, it should identify the commtter (see below) and the purpose of
the changes. It's also nice to summarize the changes -- where the log
message ends and the use of diff begins is a matter of taste and
search strategies -- and link the revision to any outside points of
reference (e.g. a bug number). The current convention is to fold all
of this into the log message, perhaps using a site-specific structure
guide. For in-house work, some of this could also be done in svn with
versioned properties and custom scripts. Whatever your current
practice with cvs is, it should be fairly easy to replicate with svn.
- States that are likely to be of interest in the future should be
easily referenced. (In other words, tags are your friends.) It
sounds like you're labelling all releases; whether or not you also
need to label intermediate points of "metastability" depends on the
project.
- Once the project is working, major changes in progress should try
not to break it. You mention that you use branches to isolate work in
progress, which is fair enough. The pitfalls here have to do with
keeping changes straight between branches (including the trunk): you
don't want one branch to drift too far away, and it's also nice if
other developers can cast an eye on changes in a branch often enough
that they'll spot problems before the branch wanders too far afield.
How this works in practice is more a matter of project culture than
the scs itself. (What merits a branch? How long-lived is it? How
are changes moved back and forth betweeen branches? Who else looks at
branches?) Most of that's outside the scope of your summary, so I
can't say much about it. The relationship you outline between
branches and releases does strike me a a little risky, though -- you
talk about releases from either the trunk or a branch, and I'm not
entirely sure how a release from a branch takes into account changes
from the trunk since the branch, or how you prevent collisions betwen
releases from different branches or the trunk (especially
near-simultaneous releases). If the goal of the branch was to isolate
potential breakage during a major change, it might be better to fold
it back into the trunk and release from there. If the goal of the
branch is to maintain a parallel (e.g. customer-specific) codebase in
perpetuity, then you'll need to keep of what changes pass back and
forth between branches and the trunk. (You might use either extensive
log messages, or a log kept as a file in the repo.)
- Parallel work shouldn't collide. At some level, this is just a
rationale for working copies. However, the down side is that
different working copies can diverge in many and twisted ways.
Therefore, this principle also serves as a rallying cry for
fine-grained commits and good branch management; see above.
This certainly isn't an exhaustive list, but it's perhaps a good
starting point for assessing your current practice.
> Many people suggest that each developer on the system should have their own
> working directory, this is not possible for us because of the way our system
> works; it has approximately 20 to 30 services binding to different ports and
> different ips all on the same machine. We also have to share the machine
> when we develop the system, this is because we follow eXtreme Programming.
If by this you mean that everyone works on the same copy of the code,
I'm not so sure it's a good idea. Leaving aside the little practical
problems like filesystem locking (what happens if two people
simultaneously edit the same file, or one person runs a build just as
an editor autosaves an in-progress edit by another person?), it makes
tracking changes tougher. Subversion goes to some trouble to record
the author of each commit; while you could all commit from a common
username and record your identity in log messages, is the extra work
worth it? It also makes conceptual "locking" tougher. For example,
even if I'm making a small change, it may require changes to both the
compiled source and to a header. It's nice for that change to appear
atomic to other developers. You can still use frequent commits and
updates to keep abreast of others' changes in a short release cycle.
If it's possible for different developers to have their own working
copies, even on the same machine, that'd probably be a better
alternative. If you really need to work from a single copy, you might
at least consider the ssh-command-with-svnserve-t trick (cf.
http://subversion.tigris.org/faq.html#ssh-svnserve-location or
http://freehackers.org/~shlomif/svn-raweb-light/subversion.cgi/trunk/notes/ssh-tricks)
to let Subversion accurately record the author of each commit.
> 1. Is it possible to set permissions on files, so that when they are
> checked out they automatically get the desired permissions on the file
> system.
The short answer is "No". The slightly longer answer is, "It
depends". You have some control by way of the svn:executable
property. You can use a script wrapper around the client to reset
permissions as you'd like, but these won't be stored in the repository
unless you track them with site-specific use of properties or
somesuch. I think there is a branch off the Subversion development
trunk that address this (check the list archives for the "meta-data
branch") but it's not at all clear to me that Subversion will ever
support this in the core for philosophical reasons (check the list
archives for the "meta-data branch"). It's also possible that another
tool built on Subversion would handle this, but I'm not aware of any
right now.
> 2. Is it possible to use SVN with PAM Authentication?
If you use httpd to serve the repos via mod_dav_svn, it can be done
with the separately available mod_auth_pam. If you make them
available via SSH (using the svn+ssh tunneling scheme), it'll use PAM
if your sshd does.
--
Regards,
Charles Bailey
Lists: bailey _dot_ charles _at_ gmail _dot_ com
Other: bailey _at_ newman _dot_ upenn _dot_ edu
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Jun 12 18:52:08 2005