Single Multi-User Checkout in Subversion - Possible?

Question

Hi,

In our organization, we have the following problem. We want to have our web tree revision-controlled, but many of us want to be able to alter (and check in) any file of that tree. We would also like there to be only a single check-out for all this because the tree is rather huge. For parts of that tree, we are currently using RCS, which allows for the behavior described above, but has several other drawbacks, of course.

Does anyone know how to do such a thing (maybe with some kind of workaround) with Subversion on a Unix server?

Answer 1

I'd suggest that you use one special account for the web tree which all developers have access to, and check out the web tree as that user.

Answer 2

Why not just check out the bit of the tree you're interested in changing? That shouldn't be a problem. Maybe I'm confused about what you mean by "a single check-out".

Answer 3

@Jesper: Yes, that would be possible. An extra account for all members, maybe with an additional sudo rule.

@Jon: The thing is that basically all of us need to change some files in some part of the tree. That's why we all need the whole tree, but we do not want to have that many check-outs.

Answer 4

In a typical SVN environment, every user has her own (complete or partial) copy of the tree, where she can do any changes she wants to perform on the tree, without disturbing or breaking her co-workers. Then she decides what to check in. All others can checkout, whenever they think it is the best time to do so. and the main (deployment) user checks out regularily (daily build) to check for integrity.

I think your confusion is RCS in comparison to CVS/subversion: RCS blocks a file for all others while editing, SVN doesn't block anything (normally. blocking is possible but rarely used).

Answer 5

@Lytha: I know that RCS is lock-based, and we have no problem with that in our scenario. I also know that you can use SVN with locking, but the per-user check-out problem persists...

Answer 6

Are the developers not on their own machines? Is the tree so huge that it must be checked-out onto a shared network drive on a server, since it doesn't fit on individual developers' workstations? I think this question needs some numbers to clarify the problems and reasoning behind it further.

Answer 7

Disk drives are cheap. Let each developer check out a copy of the tree. Subversion solves the locking issue, so each user having their own copy does not interfere with others making changes. You'll be much more productive and have better accountability for changes if each person checks out and manages their own development version of the source tree.

Answer 8

As you've probably seen from the other posts, the general answer to this issue is "Don't do that." Generally speaking, Subversion is used for individual checkouts of some or all of a repository to the local workspace.

If you absolutely, positively, must have a view of the entire repository per developer, but a developer is only changing a small portion, here's a potential solution for you. You'll need to develop a few scripts to facilitate what I'm describing (which is based on a UNIX IDE I used to use).

I'm also assuming, from your comments, that the environment is UNIX or Linux - I don't think the following is possible in Windows.

1. Check-out as read-only the entire project in some location. Ensure that all developers have read access to it.
2. Have a script a developer can execute that crawls the directory structure creating a mirror of the structure using symbolic links to the read-only directory in that developer's workspace.
3. When checking out a portion of the tree to edit, delete the symlink and check-out that path from Subversion (you'll probably want a script to wrap svn commands to handle this)
4. Either on svn commit or in a separate script, you'll probably want to delete the workspace directory and re-establish the symlink.
5. Have the read-only copy updated, either through a post-commit hook in Subversion or periodically with cron or something similar.

The symlinks provide a view of the entire tree per developer, and allow for a "local" checkout of only those portions of the tree that the developer is actively editing.

The reason for the circumlocutions is that Subversion really wasn't intended to be used in this manner. However, this method will work, with some pain, for what you describe.

Answer 9

Subversion allows you to check out any portion of the tree, and with version 1.5 also supports sparse checkouts. What this means is you can fine-tune your checkout to the individual directory level (but not as far as the individual file level as RCS can go).

So for example, if your repository looks like this:

Repository Root
  tags
  branches
  trunk
    doc
    src
      module1
        resources
      module2
    images

You can check out only the files in the module1 directory (and not its subdirectories) using this:

svn checkout --depth=files svn://server/repository/trunk/src/module1

If you also need subdirectory content you can adjust the size of your checkout later, see the documentation.

Answer 10

If it is delay/bandwidth in checking out a working copy that worries you, bear in mind that the working copy is entirely self contained. This means that you can do your checkout of a huge repository, and then simply copy that "working copy" to whoever needs it.

The same trick also works nicely for branches - if you have an unaltered recent working copy of trunk you can simply copy it and then 'svn switch' it to a new branch.

1. Checkout huge repository to base_working_copy (overnight?)
2. cp -a base_working_copy my_working_copy (and to whoever else needs it)
3. cp -a base_working_copy my_branch
4. cd my_branch
5. switch my branch to whatever branch URL

I've also used this successfully to snailmail cds of big working copies to people with bandwidth problems.

See also: using subversion with a really really big site