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

RE: File permissions behavior change from 1.2.3/1.3.0 to 1.4.x

From: Garrett McGrath <gmcgrath_at_Princeton.EDU>
Date: 2006-12-14 21:43:52 CET

These btw should be getting cc'd to the subversion user list. and that
sounds like what versions vs. trunks are used for really...


From: Steve Bakke [mailto:steven.bakke@amd.com]
Sent: Thursday, December 14, 2006 3:34 PM
To: Garrett McGrath
Subject: Re: File permissions behavior change from 1.2.3/1.3.0 to 1.4.x

No, the repository is the method for checkpointing revisions just as with
private working copies. We also publish releases in a different area which
are tied to tagged versions in the repository. The only difference is that
there may be multiple people editing data in the same working copy.

Our central working copy (we actually have at least two separate ones) only
has the latest version of things. It doesn't contain all revisions. When
we need to work with stable data such as to do a build, we checkout data
into a private working copy (either from tag or trunk).


On 12/14/06 3:07 PM, "Garrett McGrath" <gmcgrath@Princeton.EDU> wrote:

yes but what your trying to do seems counter intuitive to the way subversion
is setup to operate is what it appears like to me. That's all i'm really
saying. Basically you take subversion put it 'somewhere' using svnserve or
apache, then everyone checks out a copy locally that they work on. When you
lock a file that lock is actually done in the svn repository not the working
directory. People who don't own the lock can't commit a file involved with
that lock to the repository because it's locked not based on the permission
system that's in place. when you check out a copy from the repository all
files become 'yours' (to my understanding at least). So you should under
this model be replacing the shared working area with the physical repository
(because that's what it is anyway) and then have the people involved check
out thier copies locally to work on them.

This is just my understanding as to how subversion is 'supposed' to work.
If this was working for you before hand then i dunno what i can say to help
you there but it's not really a bug if it's not part of the way subversion
is supposed to work in the first place.


From: Steve Bakke [mailto:steven.bakke@amd.com]
Sent: Thursday, December 14, 2006 2:46 PM
To: Garrett McGrath
Subject: Re: File permissions behavior change from 1.2.3/1.3.0 to 1.4.x

That decision wasn't mine. :^) I would prefer to have private work areas.
Subversion just happened to be the choice that I made to use for revision

I mainly want subversion as a better CVS that handles binary data nicely.


On 12/14/06 2:41 PM, "Garrett McGrath" <gmcgrath@Princeton.EDU> wrote:

umm... i'm confused as to 'why' your doing this. I mean i've used a single
working copy to handle my server config file backups, but in development it
seems more practical that the developer just check out a copy for him self
as sharing a working copy seemingly eliminates what svn is actually
designed to be used for.



From: Steve Bakke [mailto:steven.bakke@amd.com]
Sent: Thursday, December 14, 2006 2:31 PM
To: users@subversion.tigris.org
Subject: File permissions behavior change from 1.2.3/1.3.0 to 1.4.x

I attempted to first raise this issue on the subversion users' mailing list
a week or two ago, but got no response. I'm pretty confident that this is
a bug or at least it is an undocumented change in behavior from prior

We have a setup where there is a centralized working copy accessed by
multiple users. As a result, having the correct permissions set on things
makes or breaks this working model. Our working copy directories are all
set up to have read+write user and group permissions.
We are working with a number of binary files that we have set up to have
needs-lock properties. Prior to subversion 1.4.0, the behavior of the
'svn lock' command was such that the user executing the command would
assume ownership of the file and get write permissions. Effectively, it
would delete the original file in the working copy and then copy a fresh
version in place. (at least this is what it appears to do) It works this
way in both 1.2.3 and 1.3.0. Meanwhile, svn unlock leaves the file
read-only across the board.
With 1.4.0, it now reports an error that it can't change the file
permissions. (I believe it is also the same with 1.4.2) This is a pretty
significant change in behavior. I imagine that most people haven't noticed
since most people use private working copies.

Can somebody confirm that this is a bug? It is very easy to reproduce. We
managed to work around the issue, but it's an ugly hack to a wrapper script
to move the file and copy it back so that the user can assume ownership and
call 'svn lock'. If somebody wants to lock a large number of files, it
takes a lot longer now.


Steve Bakke
Received on Thu Dec 14 21:44:40 2006

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.