On Dec 20, 2006, at 3:02 PM, Erik Huelsmann wrote:
> > Hi all,
>
> Hi Steve,
>
> > The new problem I am having is related, but it is more
> important. This one
> > is related to 'svn add'. We have auto-props set to apply needs-
> lock for a
> > particular type of binary files we are working with. If user 'A'
> attempts
> > to run 'svn add' on a set of files that are owned by user 'B', we
> have a
> > problem when user 'A' tries to commit the add:
>
> The assumption in the working copy code is that the user using the
> working copy at least has write access to perform the operations he
> requests. What you describe here looks like you're (partially) not
> satisfying that requirement.
>
All users always have read/write permissions on the directories
within the
working copy. The only reason I run into this issue is that file
locking
involves changing permissions back and forth from writeable to read-
only.
> The requirement has always been there (ie the 2 users must be in the
> same group and have group write perms), but with the working copy
> optimizations in 1.4, the issue has become more visible. I don't feel
> this is a bug, even though your use-case may have worked with 1.3: we
> fixed many (but surely not all) performance problems in our working
> copy code even though we remain slow from a users perspective. I don't
> think that your use case is sufficiently common enough (or even
> sufficiently compatible with Subversion philosophy of 'everybody his
> own work(ing copy)') enough to revert these performance optimizations
> and go back to the old days.
I'm not suggesting that we go back to the old days. However, I
believe that
subversion should handle the situation gracefully. The problem with
'svn lock'
and 'svn unlock' at least doesn't hose the working copy.
>
> > % svn commit –m "New stuff commit" newdir
> > Adding newdir
> > Adding newdir/layout
> > Adding (bin) newdir/layout/layout.cdb
> > Adding newdir/layout/master.tag
> > Adding newdir/layout/pc.db
> > Transmitting file data ...svn: Commit succeeded, but other
> errors follow:
> > svn: Error bumping revisions post-commit (details follow):
> > svn: In directory '/.../newdir/layout'
> > svn: Error processing command 'committed' in '/.../newdir/layout'
> > svn: Error replacing text-base of 'layout.cdb'
> > svn: Can't change perms of file
> > '/.../newdir/layout/layout.cdb': Operation not permitted
> >
In my opinion, the fact that subversion leaves the working copy in a
strange
state is bad. I don't expect most users to understand exactly how
they would
back out of this problem. The transaction "completed" yet the
working copy did
not.
If this were to be fixed in subversion, I would imagine it would
involve a simple
change:
for each needs-lock file:
1. Check the ownership of the file.
2. If the file is not owned by the current uid, then assume ownership.
3. Change file permissions
How expensive is the operation to check and compare ownership? I
suppose it is
greater than zero, since a stat() is an expensive function. What I'm
getting at is -
if I were to fix this myself in the form of a patch, would the patch
have any chance
of being approved?
A shortcut to #1 would be to check whomever last checked in the
file. That should be
the person who owns it.(although it doesn't handle the case where
somebody manually
changed ownership)
> > This seems to clearly be a bug and it is not something I want to
> workaround
> > in a wrapper script.
>
> It can't be solved by a wrapper script, other than to make the wrapper
> assume ownership of the working copy before you start 'write access
> requiring' operations (switch/update/commit).
>
> > Any thoughts?
>
> I'm sorry, but for now, I feel your requirements are conflicting with
> what the majority of users want from Subversion working copies. You
> could consider svk: it doesn't have working copies as we know them in
> Subversion, so, you probably won't run into these issues there. (They
> have XDs, which don't have admin dirs.)
Are there never cases where somebody might be doing some sort of
integration
build in a shared working copy (2 users). In the specific case of
file locks,
subversion is not handling this correctly.
If there is a way to handle this such as the fix would not impact
users with
the more typical use-case, I would like to get this fixed.
>
> bye,
>
> Erik.
>
> > -Steve
> >
> >
> > On 12/14/06 7:45 PM, "Steve Bakke" <steven.bakke@amd.com> wrote:
> >
> >
> > It's not my choice whether or not to have a shared working copy.
> Whether or
> > not this is the best working model isn't really the question.
> The reasons
> > for choosing a central working model are mainly so that the
> current state of
> > things are visible. In reality, only a small number of people
> would be
> > working in the same working directory.
> >
> > I'd rather not get caught up in a philosophical discussion on
> that issue,
> > since that part is out of my control. Does this or does this
> not seem to
> > be a bug in subversion 1.4.x? I believe that it is. My problem
> is that I
> > may be the only person to care about it. It is a clear change in
> behavior
> > from previous versions that I don't think was intentional.
> >
> > -Steve
> >
> >
> > On 12/14/06 7:02 PM, "Tim Hill" <drtimhill@comcast.net> wrote:
> >
> >
> > I'm with Garrett on this one -- I think you should carefully
> think about if
> > what you're doing is the correct approach. Basically, by sharing
> a working
> > copy you are moving outside of the "comfort zone" for Subversion
> workflows,
> > and this is really why you are seeing this problem.
> >
> > That aside, it does look like you have identified a change in
> behavior in
> > 1.4.x, though I'm not sure if I would class this as a bug or a
> bug fix <g>.
> > You might try opening a bug or checking the bug database to see
> if this was
> > a "by design" change.
> >
> > --Tim
> >
> > On Dec 14, 2006, at 12:43 PM, Garrett McGrath wrote:
> >
> >
> >
> > These btw should be getting cc'd to the subversion user list.
> and that
> > sounds like what versions vs. trunks are used for really...
> >
> > -Garrett
> >
> >
> >
> > ________________________________
> > 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).
> >
> > -Steve
> >
> > 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.
> > -Garrett
> >
> >
> > ________________________________
> > 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 control.
> >
> > I mainly want subversion as a better CVS that handles binary
> data nicely.
> >
> >
> > -Steve
> >
> >
> > On 12/14/06 2:41 PM, "Garrett McGrath"
> <gmcgrath@Princeton.EDU> wrote:
> >
> >
> >
> > Steve,
> > 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.
> > -Garrett
> >
> >
> >
> > ________________________________
> > 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 releases.
> >
> > 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.
> >
> > Thanks,
> >
> > Steve Bakke
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Dec 20 21:38:50 2006