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

Re: Web projects, commit problems & repository access

From: <cmpilato_at_collab.net>
Date: 2003-02-13 22:17:06 CET

Philip Reynolds <phil@Redbrick.DCU.IE> writes:

> Checking out the source in our home directories, would mean that
> changes go to the source first, which are then committed but then
> have to be checked out on the main source page then. This is rather
> cumbersome, especially in the development of a new system, where
> changes are constantly being made.
> What alternatives have people had with this?

You could write a post-commit hook that update your "live" working

> One minor problem I've run into, is with using ``svn commit''. It
> seems to leave a svm-commit-XXX.tmp file in the current directory,
> if you allow it to open up an editor to create the commit message.

This should only happen if the commit fails (though it was a bug for a
while). Try updating to a newer version of Subversion.

> Ok, one last problem I can't seem to fix, is the issue where
> ``user1'' creates a repository (svnadmin create) and wants to allow
> ``user2'' full access to it (adding, reverting, deleting,
> commiting).
> In this situation, both users will be using checked out versions on
> the same machine, so we're using file:/// URL's to access the
> repository. I can only presume this is done using UNIX file
> permissions, however I can't see this described anywhere.
> Perhaps someone could shed some light on this.

This is a complicated problem that I've not yet solved. To be honest,
I just punt and use HTTP/DAV even when accessing repositories on the
same machine as the server. I suppose some combination of Unix group
permissions and creative umasks() or sticky bits could do the job,

> Apologies if these questions are answered somewhere, I've read the
> excellent ``Subversion: The definitive Guide'' by Ben
> Collins-Sussman, Brian W. Fitzpatrick, and C. Michael Pilato and the
> FAQ to no avail. Searching the mailing lists didn't seem to crop up
> much either. Feel free to point out documentation or information
> I've missed somewhere.

Er... sorry about that. If you do come up with a solution, please let
me know so that I can update Chapter 5 in the book. :-)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 13 22:18:10 2003

This is an archived mail posted to the Subversion Dev mailing list.