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

Pair Programming with Subversion

From: <andy.glew_at_amd.com>
Date: 2004-03-30 23:02:58 CEST

---+ Brief

Can Subversion be set up so that two users,
with different user IDs, can share the same
workspace, taking turns checking files in,

I am trying to practice pair programming,
working with my partner in the same directory,
and the "svn" client program keeps having
filesystem permission and file ownership issues.

---+ Detail

---++ My Background

I'm new to Subversion, although I am a
fairly experienced user of other version
control tools

I've contributed code to
RCS (and maybe CVS, if they ever accept
my changes), set up VC for several large
projects and companies, and years ago
wrote a paper "Boxes Links and Parallel
Trees" which Brian Beliner dissed in the
CVS paper (apparently Brian did not read
the part about "Optimistic Concurrency Control")).

I version control *everything*, including
my home directory.

---++ The Problem

In XP (eXtreme Programming) Pair Programming, 2 programmers
work closely together. Some people have 2 programmers
sharing a monitor, mouse, and keyboard; I practice a variant
where both of us have our own computers, and are logged
in separately, but where we work, at the same time, in
the same directory. We do things like one guy working
on a test while the other guy checks in the code, etc.

We change roles frequently: first I check in, then my
partner uses the version control tool, etc.

Doing this with CVS was not a problem: we set the appropriate
umask, and it all just worked.

Doing this with Subversion so far seems so inconvenient
as to be impossible. We keep getting errors, such as
Subversion wanting to change the ownership or permissions
of the log file, which was created with my partner's user ID
but which Subversion now needs to be owned by me since
I am running "svn ci".

We have been able to fix all such problems by finding the
problem file, copying it to a file I own, removing the
file my partner owns, and then renaming the file I own back
in the original place. But that sucks.

In UNIX parlance, the Subversion client seems to be doing
operations modifying an existing file, instead of making a copy
and replacing the original.

I suppose that I should not be too mad at Subversion:
if the UNIX filesystem were decent, it would have an access
right that gives somebody else the ability to take ownership
of a file, or to change permissions on a file by someone
other than the owner.

But it doesn't: I'm stuck with the standard UNIX file permission

So my question / earnest hope is: is there any way of using
Subversion in this pair programming style?

the only thing that we have come up with so far is for all
the Subversion commands to be run by a single user ID.
I'm considering making them SETUID.

But these suck, and I hope that the Subversion client
really is multiuser friendly.

---++ It's not just Pair Programming

This Subversion behaviour is not just a problem with
Pair Programming. It can also be a problem with any
set of checked out files, where different people can
execute "svn ci", etc.

For example, I version control everything, including
the root of a project filesystem, /proj/ProjectName.
Files under /proj/ProjectName can be manipulated by
anyone in the project administrator group.
That's easy to do with UNIX filesystem permissions.

However, "svn ci" apparently cannot be used for
such files... the svn client seems to have problems
whenever it is run by someone other than the user
who did the checkout and owns the .svn files.

---++ We've seen this before

This sort of problem is familiar to many users.
RCS went through the same issue, as did CVS;
many other UNIX tools have learned this the hard way.

---++ Version

Subversion 0.34.0

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 30 23:10:17 2004

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.