Re: infinite recursive merging
On Wed, Nov 13, 2013 at 02:05:53PM +0100, nico wrote: > Hello dear SVN users, > > I have a problem with the merging mecanism in SVN. > > Here is a litttle case study: > We have 2 branches (B1, and B2) and the trunk (T), if you do the following: > commit -> Branch > merge B1 -> T > merge T -> B2 (to propagate the change) > Then if I look to which changes are eligible for merging from B2 to the > trunk, the T->B2 is eligible !!! > > It shouldn't be the case, right ? because the merginfo should be able to > track it back to the already merged change from B1 ->T. > > Am I right in my assumption ? > Can somebody explain me ? > > thanks a lot, > nico > > -- > |_|0|_| > |_|_|0| Nicolas HUOT > |0|0|0| Do you believe it is safe to assume that the B1->T merge applies the same semantic changes as the T->B2 merge? If so, do you still believe so if you take into account additional changes made for conflict resolution during merges? Couple that with the fact that merge-tracking considers a path+revision pair is the basic unit of a change set, with no ability to consider just a subset of changes made to a file in a given revision, and the problem should become apparent. If Subversion assumed that B1->T == T->B2, it might miss additional changes that may have been needed as part the B1->T merge. The B1->T merge creates a new T@REVISION_Y, i.e. a changeset T@X->T@Y that might differ from the merged change on made on B1. I think it would be wrong for Subversion to ignore these additional changes during the T->B2 merge. It is unclear to me what exactly you mean with "commit -> Branch". Can you clarify what that is supposed to mean? If it is a commit made on B2, you're merging that change in a cyclic way, since the change eventually ends up in B2 again. That will invariably result in problems, for virtually any given version control system (yes, some cope better than others, but the core problem here is that software doesn't grasp the semantics of a change). You'll get repeated applications of the same changeset, and will need to resolve conflicts because of that since there is no way to make a smart decision in software. Generally, the best way to avoid this problem is to not merge in cycles. Draw a flow diagram of your branches, with arrows to indicate possible merges between them. If you follow these arrows and ever end up merging a change that originated from a given branch to that same branch again, your merging strategy is flawed because it will trigger unneeded conflicts.
Method not allowed exception
Hi to all, while upgrading the subversion repository to version 1.8.4 the external technician has also changed the folder name without notice. I lost many hours because I haven't understood immediately that "method not allowed" means "url not found" (in my case). It's possible to change the feedback? IMHO "method not allowed" means that the url is ok but I don't have required permissions on some objects. Stefano Fraccaro
svn delete removes read-only files
Hello, At my company we are using the lock-modify-unlock model, with the svn:needs-lock property set on most files. We have a pre-commit hook that prevents committing unlocked files. We are currently on Subversion 1.6.6. Here is a typical frustrating sequence that happens when removing files: # User deletes file, forgetting to get the lock first. $ svn rm foo.txt D foo.txt # User tries to commit. $ svn ci -m "deleted foo.txt" Deleting foo.txt svn: Commit failed (details follow): svn: Commit blocked by pre-commit hook (exit code 1) with output: ... # Argh! User tries to lock the deleted file, so commit can proceed. svn lock foo.txt svn: Can't change perms of file '/home/varney/foo.txt': No such file or directory # Curses! Foiled again! # Actually, the user did get the lock, but doesn't realize it, because svn gave an error message. # At this point the user contacts me for help. While I understand why svn behaves this way, it *is* counter-intuitive. Here is my suggestion for a change to how svn delete behaves, to avoid this situation: Modify svn delete so it refuses to remove read-only files. This way, the need to lock becomes more intuitive to users, in the same way locking a file opens up write permissions so a file can be edited. What do you think? Any alternatives I have not considered? Should I open a feature request for this? Best regards, Rick Varney
Re: svn delete removes read-only files
On 14.11.2013 19:24, Rick Varney wrote: > Hello, > > At my company we are using the lock-modify-unlock model, with the > svn:needs-lock property set on most files. We have a pre-commit hook > that prevents committing unlocked files. We are currently on > Subversion 1.6.6. > > Here is a typical frustrating sequence that happens when removing files: > > # User deletes file, forgetting to get the lock first. > $ svn rm foo.txt > D foo.txt > > # User tries to commit. > $ svn ci -m "deleted foo.txt" > Deleting foo.txt > svn: Commit failed (details follow): > svn: Commit blocked by pre-commit hook (exit code 1) with output: > ... > > # Argh! User tries to lock the deleted file, so commit can proceed. > svn lock foo.txt > svn: Can't change perms of file '/home/varney/foo.txt': No such file > or directory > > # Curses! Foiled again! > # Actually, the user did get the lock, but doesn't realize it, because > svn gave an error message. Good catch; this is the actual bug. It's OK to lock a nonexistent path, and if the lock had been acquired on the file's URL instead of the working copy path, it would most likely work without emitting an error. > # At this point the user contacts me for help. > > While I understand why svn behaves this way, it *is* counter-intuitive. > > Here is my suggestion for a change to how svn delete behaves, to avoid > this situation: > > Modify svn delete so it refuses to remove read-only files. This way, > the need to lock becomes more intuitive to users, in the same way > locking a file opens up write permissions so a file can be edited. > > What do you think? Any alternatives I have not considered? Should I > open a feature request for this? I disagree with the behaviour change because it makes 'svn delete' in the presence of svn:needs-lock behave exactly opposite to every other command. IMO, it's quite enough to simply fix the bug where we try to change the permissions on a non-existent local path. So I suggest you file a bug for that, not for the behaviour change. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: svn delete removes read-only files
Branko Čibej writes: > On 14.11.2013 19:24, Rick Varney wrote: >> We are currently on Subversion 1.6.6. >> What do you think? Any alternatives I have not considered? Should I >> open a feature request for this? > > I disagree with the behaviour change because it makes 'svn delete' in > the presence of svn:needs-lock behave exactly opposite to every other > command. IMO, it's quite enough to simply fix the bug where we try to > change the permissions on a non-existent local path. > > So I suggest you file a bug for that, not for the behaviour change. We won't fix this in 1.6 and 1.8 is already fixed: $ svn rm wc/A/f D wc/A/f $ svn st wc/A/f D wc/A/f $ svn lock wc/A/f 'f' locked by user 'pm'. $ svn st wc/A/f DK wc/A/f -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: svn delete removes read-only files
On 14.11.2013 21:44, Philip Martin wrote: > Branko Čibej writes: > >> On 14.11.2013 19:24, Rick Varney wrote: >>> We are currently on Subversion 1.6.6. >>> What do you think? Any alternatives I have not considered? Should I >>> open a feature request for this? >> I disagree with the behaviour change because it makes 'svn delete' in >> the presence of svn:needs-lock behave exactly opposite to every other >> command. IMO, it's quite enough to simply fix the bug where we try to >> change the permissions on a non-existent local path. >> >> So I suggest you file a bug for that, not for the behaviour change. > We won't fix this in 1.6 and 1.8 is already fixed: > > $ svn rm wc/A/f > D wc/A/f > $ svn st wc/A/f > D wc/A/f > $ svn lock wc/A/f > 'f' locked by user 'pm'. > $ svn st wc/A/f > DK wc/A/f Yes, I was just going to say. I added test cases for this on trunk, and they passed; I've just been running them on 1.8, where they pass as well. In other words, upgrading to 1.8 will fix the issue, and in the meantime, ask your users to either revert the delete first (i.e., 'svn revert file; svn lock file; svn rm file; svn commit', or to use the URL in the 'svn lock' command. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: svn delete removes read-only files
On 14.11.2013 21:54, Branko Čibej wrote: > On 14.11.2013 21:44, Philip Martin wrote: >> Branko Čibej writes: >> >>> On 14.11.2013 19:24, Rick Varney wrote: We are currently on Subversion 1.6.6. What do you think? Any alternatives I have not considered? Should I open a feature request for this? >>> I disagree with the behaviour change because it makes 'svn delete' in >>> the presence of svn:needs-lock behave exactly opposite to every other >>> command. IMO, it's quite enough to simply fix the bug where we try to >>> change the permissions on a non-existent local path. >>> >>> So I suggest you file a bug for that, not for the behaviour change. >> We won't fix this in 1.6 and 1.8 is already fixed: >> >> $ svn rm wc/A/f >> D wc/A/f >> $ svn st wc/A/f >> D wc/A/f >> $ svn lock wc/A/f >> 'f' locked by user 'pm'. >> $ svn st wc/A/f >> DK wc/A/f > > Yes, I was just going to say. I added test cases for this on trunk, > and they passed; I've just been running them on 1.8, where they pass > as well. > > In other words, upgrading to 1.8 will fix the issue, and in the > meantime, ask your users to either revert the delete first (i.e., 'svn > revert file; svn lock file; svn rm file; svn commit', or to use the > URL in the 'svn lock' command. And here's the related issue: http://subversion.tigris.org/issues/show_bug.cgi?id=4304 -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Method not allowed exception
On 11/14/13 2:07 AM, Stefano Fraccaro wrote: > while upgrading the subversion repository to version 1.8.4 the external > technician has also changed the folder name without notice. I lost many hours > because I haven't understood immediately that "method not allowed" means "url > not found" (in my case). It's possible to change the feedback? > IMHO "method not allowed" means that the url is ok but I don't have required > permissions on some objects. Can you elaborate what method you're seeing method not allowed with? Or if you were running a svn client what command you were running? The one case where we made such a change that comes to mind is with LOCK. LOCK per the RFC can lock files that don't exist (otherwise known as an unmapped url or null resources). http://webdav.org/specs/rfc4918.html#lock-unmapped-urls http://webdav.org/specs/rfc2518.html#rfc.section.7.4 We only support this when SVNAutoversioning is turned on and return a method not allowed error if this isn't turned on. We felt that the method not allowed error was the logical error to return. The other cases where we return method not allowed typically are cases where we don't allow that method on regular URLs unless auto-versioning is enabled.
Re: Method not allowed exception
Il 14/11/2013 22:35, Ben Reser ha scritto: Can you elaborate what method you're seeing method not allowed with? Or if you were running a svn client what command you were running? TortoiseSVN > SVN Checkout The one case where we made such a change that comes to mind is with LOCK. LOCK per the RFC can lock files that don't exist (otherwise known as an unmapped url or null resources). http://webdav.org/specs/rfc4918.html#lock-unmapped-urls http://webdav.org/specs/rfc2518.html#rfc.section.7.4 We only support this when SVNAutoversioning is turned on and return a method not allowed error if this isn't turned on. We felt that the method not allowed error was the logical error to return. The other cases where we return method not allowed typically are cases where we don't allow that method on regular URLs unless auto-versioning is enabled. We have an apache installation with subversion modules ( http://webserver/ ). All our repositories are in svn subfolder ( http://webserver/svn/RepositoryName ) If I checkout the url 'http://webserver/badname/RepositoryName', subversion return '405 Method not allowed' instead of '404 Url not found'. Unexpected HTTP status 405 Method Not Allowed on '/badname/RepositoryName' Additional errors: PROPFIND request on '/badname/RepositoryName' failed: 405 Method not allowed
Re: Method not allowed exception
On 15.11.2013 07:47, Stefano Fraccaro wrote: > Il 14/11/2013 22:35, Ben Reser ha scritto: >> Can you elaborate what method you're seeing method not allowed with? >> Or if you >> were running a svn client what command you were running? > TortoiseSVN > SVN Checkout >> >> The one case where we made such a change that comes to mind is with >> LOCK. LOCK >> per the RFC can lock files that don't exist (otherwise known as an >> unmapped url >> or null resources). >> >> http://webdav.org/specs/rfc4918.html#lock-unmapped-urls >> http://webdav.org/specs/rfc2518.html#rfc.section.7.4 >> >> We only support this when SVNAutoversioning is turned on and return a >> method >> not allowed error if this isn't turned on. We felt that the method >> not allowed >> error was the logical error to return. >> >> The other cases where we return method not allowed typically are >> cases where we >> don't allow that method on regular URLs unless auto-versioning is >> enabled. >> > > We have an apache installation with subversion modules ( > http://webserver/ ). > All our repositories are in svn subfolder ( > http://webserver/svn/RepositoryName ) > If I checkout the url 'http://webserver/badname/RepositoryName', > subversion > return '405 Method not allowed' instead of '404 Url not found'. > > > Unexpected HTTP status 405 Method Not Allowed on > '/badname/RepositoryName' > Additional errors: > PROPFIND request on '/badname/RepositoryName' failed: 405 Method not > allowed I think you are mistaken, this error probably not returned by Subversion (since it's not configured on that location) but by the Apache HTTPd server itself. Most likely your server interprets the request as a PROPFIND on directory "badname" within the directory defined by the server configuration option DocumentRoot. The default server configuration probably only allows GET requests on such paths; which makes a kind of sense, since the PROPFIND method is defined by the DAV protocol, not HTTP itself. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
