[jira] [Updated] (SVN-2516) --revision option is not forwarded to svn:externals references

2015-10-01 Thread Ivan Zhakov (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SVN-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Zhakov updated SVN-2516:
-
Description: 
When you do 'svn up -rN' or 'svn export -rN', svn:externals underneath do not 
respond to the -rN, even if the {{svn:externals}} values do not have specific 
-r values themselves.  We could detect when the externals are from the same 
repository as the primary target of the update and have the externals use the 
same revision.  There would be a compatibility issue, but note that the 
workaround is simply to explicitly pass -rHEAD in the externals description, 
since -rHEAD is the default behavior
right now.

This mail describes the problem and provides a script to demonstrate it:
{quote}
http://subversion.tigris.org/servlets/ReadMsg?list=users=45802
From: j...@jmason.org (Justin Mason)
To: us...@subversion.tigris.org
Cc: d...@spamassassin.apache.org
Subject: iffy behaviour with SVN external and "svn up -r"
Date: Wed, 01 Mar 2006 12:00:55 +
Message-Id: <20060301120055.2236d590...@radish.jmason.org>
{quote}

See comments in issue SVN-2209 about some of the infrastructure needed to 
implement this enhancement.


  was:
{noformat:nopanel=true}
When you do 'svn up -rN' or 'svn export -rN', svn:externals underneath
do not respond to the -rN, even if the svn:externals values do not
have specific -r values themselves.  We could detect when the externals
are from the same repository as the primary target of the update and
have the externals use the same revision.  There would be a compatibility
issue, but note that the workaround is simply to explicitly pass -rHEAD
in the externals description, since -rHEAD is the default behavior
right now.

This mail describes the problem and provides a script to demonstrate it:

   http://subversion.tigris.org/servlets/ReadMsg?list=users=45802
   From: j...@jmason.org (Justin Mason)
   To: us...@subversion.tigris.org
   Cc: d...@spamassassin.apache.org
   Subject: iffy behaviour with SVN external and "svn up -r"
   Date: Wed, 01 Mar 2006 12:00:55 +
   Message-Id: <20060301120055.2236d590...@radish.jmason.org>

See comments in issue #2209 about some of the infrastructure needed to
implement this enhancement.
{noformat}


> --revision option is not forwarded to svn:externals references
> --
>
> Key: SVN-2516
> URL: https://issues.apache.org/jira/browse/SVN-2516
> Project: Subversion
>  Issue Type: Improvement
>  Components: libsvn_wc
>Affects Versions: trunk
>Reporter: Karl Fogel
> Fix For: unscheduled
>
>
> When you do 'svn up -rN' or 'svn export -rN', svn:externals underneath do not 
> respond to the -rN, even if the {{svn:externals}} values do not have specific 
> -r values themselves.  We could detect when the externals are from the same 
> repository as the primary target of the update and have the externals use the 
> same revision.  There would be a compatibility issue, but note that the 
> workaround is simply to explicitly pass -rHEAD in the externals description, 
> since -rHEAD is the default behavior
> right now.
> This mail describes the problem and provides a script to demonstrate it:
> {quote}
> http://subversion.tigris.org/servlets/ReadMsg?list=users=45802
> From: j...@jmason.org (Justin Mason)
> To: us...@subversion.tigris.org
> Cc: d...@spamassassin.apache.org
> Subject: iffy behaviour with SVN external and "svn up -r"
> Date: Wed, 01 Mar 2006 12:00:55 +
> Message-Id: <20060301120055.2236d590...@radish.jmason.org>
> {quote}
> See comments in issue SVN-2209 about some of the infrastructure needed to 
> implement this enhancement.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SVN-2507) 'commit --no-unlock' doesn't remove locks on files deleted

2015-10-01 Thread Ivan Zhakov (JIRA) 

[ 
https://issues.apache.org/jira/browse/SVN-2507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14922977#comment-14922977
 ] 

Ivan Zhakov edited comment on SVN-2507 at 10/1/15 5:46 PM:
---

Another consequence of not removing these locks is that it can result in locks 
on directories when a commit replaces a file with a directory:
{noformat}
svnadmin create repo
svn import -mm repo/format file://`pwd`/repo/X
svn co file://`pwd`/repo wc
svn lock wc/X
svn rm wc/X
svn mkdir wc/X
svn ci -mm wc --no-unlock
{noformat}

Now X is a locked directory:

{noformat}
$ svn info file://`pwd`/repo/X
Path: X
URL: file:///home/pm/sw/subversion/obj5/repo/X
Relative URL: ^/X
Repository Root: file:///home/pm/sw/subversion/obj5/repo
Repository UUID: 54a02543-7c52-41b1-aeb3-bdab691dd3e6
Revision: 2
Node Kind: directory
Last Changed Author: pm
Last Changed Rev: 2
Last Changed Date: 2015-09-24 22:56:51 +0100 (Thu, 24 Sep 2015)
Lock Token: opaquelocktoken:2b9e70e9-d592-4be8-a0d0-fe6d3b2c7837
Lock Owner: pm
Lock Created: 2015-09-24 22:56:51 +0100 (Thu, 24 Sep 2015)
{noformat}

and that leads to things like:

{noformat}
svn co file://`pwd`/repo wc
svn ps p v wc/X
svn ci -mm wc
svn: E195022: Directory '/home/pm/sw/subversion/obj5/wc/X' is locked in another 
working copy
{noformat}



was (Author: philipm):
{noformat:nopanel=true}
Another consequence of not removing these locks is that it can result in locks
on directories when a commit replaces a file with a directory:

svnadmin create repo
svn import -mm repo/format file://`pwd`/repo/X
svn co file://`pwd`/repo wc
svn lock wc/X
svn rm wc/X
svn mkdir wc/X
svn ci -mm wc --no-unlock

Now X is a locked directory:

$ svn info file://`pwd`/repo/X
Path: X
URL: file:///home/pm/sw/subversion/obj5/repo/X
Relative URL: ^/X
Repository Root: file:///home/pm/sw/subversion/obj5/repo
Repository UUID: 54a02543-7c52-41b1-aeb3-bdab691dd3e6
Revision: 2
Node Kind: directory
Last Changed Author: pm
Last Changed Rev: 2
Last Changed Date: 2015-09-24 22:56:51 +0100 (Thu, 24 Sep 2015)
Lock Token: opaquelocktoken:2b9e70e9-d592-4be8-a0d0-fe6d3b2c7837
Lock Owner: pm
Lock Created: 2015-09-24 22:56:51 +0100 (Thu, 24 Sep 2015)

and that leads to things like:

svn co file://`pwd`/repo wc
svn ps p v wc/X
svn ci -mm wc
svn: E195022: Directory '/home/pm/sw/subversion/obj5/wc/X' is locked in another
working copy

{noformat}


> 'commit --no-unlock' doesn't remove locks on files deleted
> --
>
> Key: SVN-2507
> URL: https://issues.apache.org/jira/browse/SVN-2507
> Project: Subversion
>  Issue Type: Bug
>  Components: libsvn_client, libsvn_fs
>Affects Versions: 1.3.x
>Reporter: Stefan Küng
> Fix For: unscheduled
>
>
> As reported here:
> http://subversion.tigris.org/servlets/BrowseList?list=dev=thread=433823
> Filing issue with permission of Ben Collins-Sussman:
> When a commit deletes a file, and the --no-unlock option is passed with the 
> commit, the lock is not removed. That leaves a lock on a  non-existing file:
> {noformat}
> $ svnadmin create lockrepo
> $ svn co file:///d:/test/lockrepo lockwc
> $ cd lockwc
> $ echo test > file
> $ svn add file
> $ svn ci -m ""
> $ svn lock file
> $ svn rm file
> $ svn ci -m "" file --no-unlock
> $ echo test2 > file
> $ svn add file
> $ svn ci -m ""
> Adding   file
> svn: commit failed (details follow):
> svn: Cannot verify lock on path '/file'; no matching lock-token available
> {noformat}
> I'm not sure if that really intended. Of course, the above recipe isn't that 
> 'real life', but imagine a commit with --no-unlock where not just the removed 
> file but multiple other files are committed too, then the --no-unlock option 
> makes more sense.
> I think in case a file gets removed from the repository, the lock should be 
> removed too, no matter if the --no-unlock option is passed or not.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SVN-2507) 'commit --no-unlock' doesn't remove locks on files deleted

2015-10-01 Thread Ivan Zhakov (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SVN-2507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Zhakov updated SVN-2507:
-
Description: 
As reported here:
http://subversion.tigris.org/servlets/BrowseList?list=dev=thread=433823

Filing issue with permission of Ben Collins-Sussman:

When a commit deletes a file, and the --no-unlock option is passed with the 
commit, the lock is not removed. That leaves a lock on a  non-existing file:

{noformat}
$ svnadmin create lockrepo
$ svn co file:///d:/test/lockrepo lockwc
$ cd lockwc
$ echo test > file
$ svn add file
$ svn ci -m ""
$ svn lock file
$ svn rm file
$ svn ci -m "" file --no-unlock
$ echo test2 > file
$ svn add file
$ svn ci -m ""
Adding   file
svn: commit failed (details follow):
svn: Cannot verify lock on path '/file'; no matching lock-token available
{noformat}

I'm not sure if that really intended. Of course, the above recipe isn't that 
'real life', but imagine a commit with --no-unlock where not just the removed 
file but multiple other files are committed too, then the --no-unlock option 
makes more sense.

I think in case a file gets removed from the repository, the lock should be 
removed too, no matter if the --no-unlock option is passed or not.


  was:
{noformat:nopanel=true}
As reported here:
http://subversion.tigris.org/servlets/BrowseList?list=dev=thread=433823

Filing issue with permission of Ben Collins-Sussman:

When a commit deletes a file, and the --no-unlock option is passed with 
the commit, the lock is not removed. That leaves a lock on a 
non-existing file:

$ svnadmin create lockrepo
$ svn co file:///d:/test/lockrepo lockwc
$ cd lockwc
$ echo test > file
$ svn add file
$ svn ci -m ""
$ svn lock file
$ svn rm file
$ svn ci -m "" file --no-unlock
$ echo test2 > file
$ svn add file
$ svn ci -m ""
Adding   file
svn: commit failed (details follow):
svn: Cannot verify lock on path '/file'; no matching lock-token available

I'm not sure if that really intended. Of course, the above recipe isn't 
that 'real life', but imagine a commit with --no-unlock where not just 
the removed file but multiple other files are committed too, then the 
--no-unlock option makes more sense.

I think in case a file gets removed from the repository, the lock should 
be removed too, no matter if the --no-unlock option is passed or not.
{noformat}

Component/s: libsvn_client

> 'commit --no-unlock' doesn't remove locks on files deleted
> --
>
> Key: SVN-2507
> URL: https://issues.apache.org/jira/browse/SVN-2507
> Project: Subversion
>  Issue Type: Bug
>  Components: libsvn_client, libsvn_fs
>Affects Versions: 1.3.x
>Reporter: Stefan Küng
> Fix For: unscheduled
>
>
> As reported here:
> http://subversion.tigris.org/servlets/BrowseList?list=dev=thread=433823
> Filing issue with permission of Ben Collins-Sussman:
> When a commit deletes a file, and the --no-unlock option is passed with the 
> commit, the lock is not removed. That leaves a lock on a  non-existing file:
> {noformat}
> $ svnadmin create lockrepo
> $ svn co file:///d:/test/lockrepo lockwc
> $ cd lockwc
> $ echo test > file
> $ svn add file
> $ svn ci -m ""
> $ svn lock file
> $ svn rm file
> $ svn ci -m "" file --no-unlock
> $ echo test2 > file
> $ svn add file
> $ svn ci -m ""
> Adding   file
> svn: commit failed (details follow):
> svn: Cannot verify lock on path '/file'; no matching lock-token available
> {noformat}
> I'm not sure if that really intended. Of course, the above recipe isn't that 
> 'real life', but imagine a commit with --no-unlock where not just the removed 
> file but multiple other files are committed too, then the --no-unlock option 
> makes more sense.
> I think in case a file gets removed from the repository, the lock should be 
> removed too, no matter if the --no-unlock option is passed or not.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)