Re: [vcs] Subversion http:// Test Case

[Leo Donahue]

Just ignore this...
One of those days.


On Wed, Oct 24, 2018, 17:07 Leo Donahue  wrote:

> Debian GNU/Linux 9.5 (stretch)
> Linux 4.9.0-8-amd64 x86_64
> openjdk version "11.0.1" 2018-10-16
> OpenJDK Runtime Environment 18.9 (build 11.0.1+13)
> OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode)
> svn, version 1.9.5 (r1770682)
>compiled Jun 30 2018, 13:44:22 on x86_64-pc-linux-gnu
>
> Checking out from the repository works fine in NetBeans, when you use the
> full repository name url:
> http://subversion.hermosca.com/svn/repo1  (internal to me URL)
>
> You can web browse just this part of the URL:
> http://subversion.hermosca.com/svn/
>
> However, what works in a browser throws an error in the NetBeans log
> output.
>
> INFO [org.netbeans.modules.subversion]:
> org.apache.subversion.javahl.ClientException: Can't create session
> svn: Unable to connect to a repository at URL '
> http://subversion.hermosca.com/svn'
> RA layer request failed
> svn: Unexpected server error 500 'Internal Server Error' on '/svn'
>
> org.apache.subversion.javahl.ClientException: Can't create session
> svn: Unable to connect to a repository at URL '
> http://subversion.hermosca.com/svn'
> RA layer request failed
> svn: Unexpected server error 500 'Internal Server Error' on '/svn'
>
> at org.apache.subversion.javahl.SVNClient.info(Native Method)
> at org.apache.subversion.javahl.SVNClient.info2(SVNClient.java:797)
> at
> org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.getInfo(AbstractJhlClientAdapter.java:2144)
> Caused: org.tigris.subversion.svnclientadapter.SVNClientException
> at
> org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.getInfo(AbstractJhlClientAdapter.java:2158)
> at
> org.tigris.subversion.svnclientadapter.AbstractClientAdapter.getInfo(AbstractClientAdapter.java:310)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.netbeans.modules.subversion.client.SvnClientInvocationHandler.handle(SvnClientInvocationHandler.java:436)
> at
> org.netbeans.modules.subversion.client.SvnClientInvocationHandler.invokeMethod(SvnClientInvocationHandler.java:381)
> at
> org.netbeans.modules.subversion.client.SvnClientInvocationHandler.invoke(SvnClientInvocationHandler.java:189)
> at com.sun.proxy.$Proxy34.getInfo(Unknown Source)
> [catch] at
> org.netbeans.modules.subversion.ui.wizards.repositorystep.RepositoryStep$RepositoryStepProgressSupport.perform(RepositoryStep.java:204)
> at
> org.netbeans.modules.subversion.client.SvnProgressSupport.performIntern(SvnProgressSupport.java:86)
> at
> org.netbeans.modules.subversion.client.SvnProgressSupport.run(SvnProgressSupport.java:79)
> at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
> at
> org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
> at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
> at
> org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
>

Re: [vcs] Subversion - Checkout

[Niklas Matthies]

On Thu 2018-04-05 at 16:03h, Leo Donahue wrote on netcat:
> Thanks for clarification on the cached credentials.
> 
> Test case #1 file in Project 1 is locked.
> Test case #4 file with same name like in previous, file with same name like
> in previous, file with same name like in previous - is the same file as
> test case #1 in project 1.
> The menu option to even try to lock this file from Project 1 isn't
> available. unlock only.  I got confused as to whether the file is supposed
> to be locked or the menu items aren't working right.

Test case #3 steals the lock from Project1 to Project2, but Projec1
still believes it has the lock. I now agree there is a problem with
test case #4. Project1 needs to be updated first so that it notices
that its lock was stolen. Then the lock action is available again and
the test case can proceed as described. Maybe you could amend the test
case accordingly.

There is an actual issue when trying to unlock a lock that has been
stolen away. SVN output indicates that the lock isn't valid [1], but
NetBeans ignores this and doesn't notify the user that the action
failed and that the working copy needs an update. I'll create a Jira
issue for that tomorrow (have to leave now).

Niklas

[1]
unlock  
Filesystem has no such lock
svn: No lock on path '' (400 Bad Request)


-
To unsubscribe, e-mail: netcat-unsubscr...@netbeans.apache.org
For additional commands, e-mail: netcat-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: [vcs] Subversion - Checkout

[Leo Donahue]

Thanks for clarification on the cached credentials.

Test case #1 file in Project 1 is locked.
Test case #4 file with same name like in previous, file with same name like
in previous, file with same name like in previous - is the same file as
test case #1 in project 1.
The menu option to even try to lock this file from Project 1 isn't
available. unlock only.  I got confused as to whether the file is supposed
to be locked or the menu items aren't working right.

On Thu, Apr 5, 2018 at 3:28 PM, Niklas Matthies  wrote:

> On Thu 2018-04-05 at 12:44h, Leo Donahue wrote on netcat:
> > Thank you Niklas,
> >
> > >> SVN does not store the username in the working copy
> > http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html
> >
> > The svn redbook seems misleading.
> > "The fact that the *svn info* command, which does not contact the
> > repository when run against working copy paths, can display the lock
> token
> > reveals an important piece of information about those tokens: they are
> > cached in the working copy"
>
> Not sure what is misleading here. The lock token is the result of
> creating a lock. The username used for creating a lock is taken from
> cached credentials. Cached credentials are independent of working
> copy and not stored in the working copy. Only the resulting lock token
> and the lock owner (username who created the lock) is stored in the
> working copy. The lock owner username is not used for general SVN
> authentication, only for authorization of operations relating to that
> specific lock.
>
> See also:
> http://svnbook.red-bean.com/nightly/en/svn.serverconfig.netmodel.html#svn.
> serverconfig.netmodel.creds
> http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html
>
> > All of the files in .subversion/auth on my workstation and subversion
> > server are empty.  I thought those were used for svnserve?
>
> Ah, NetBeans sets it to ${netbeans-userdir}/config/svn/config/auth it
> seems.
> In any case, it's not saved per-working copy.
>
> > Lock Feature test suite doesn't indicate what kind of repository to use.
>
> The kind of repository should not be relevant for this.
>
> > I closed NetBeans, leaving these two projects in the state they were
> when I
> > emailed.
> :
> > The dialog that opened asking me for user credentials, I supply "user1"
> > credentials and get this error in log:
> >
> > unlock  /home/leo/workspace/netbeans/test1/Project1/src/project1/
> Main.java
> > Username does not match lock owner
> > svn: Unlock of 'Main.java' failed (403 Forbidden)
>
> That seems correct to me, since the lock was created by user2 and you
> are trying to unlock it as user1.
>
> > For Lock Features test suite, if I use the same single user credentials
> to
> > lock a file in test case #1, why would test case #4 even have the option
> to
> > "Lock" the same file again?  And Lock it again in test case #5?
>
> It's the same file, but in a different working copy (Project1 vs
> Project2). Locks are working-copy specific (by means of the lock token
> stored in the working copy). Test cases #3 and #4 are testing that you
> can "steal" a lock owned by one working copy to another working copy
> using the "force" option.
>
> Test case #5 says "select some Java file" in step 1. It is implicit
> that this should be a file that isn't locked yet, although I agree it
> would be better if the test case made this explicit. Test case #5 is
> testing that the lock is actually doing its job, namely preventing
> commits from another working copy to the locked file.
>
> Niklas
>
> -
> To unsubscribe, e-mail: netcat-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: netcat-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>

Re: [vcs] Subversion - Checkout

[Niklas Matthies]

On Thu 2018-04-05 at 12:44h, Leo Donahue wrote on netcat:
> Thank you Niklas,
> 
> >> SVN does not store the username in the working copy
> http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html
> 
> The svn redbook seems misleading.
> "The fact that the *svn info* command, which does not contact the
> repository when run against working copy paths, can display the lock token
> reveals an important piece of information about those tokens: they are
> cached in the working copy"

Not sure what is misleading here. The lock token is the result of
creating a lock. The username used for creating a lock is taken from
cached credentials. Cached credentials are independent of working
copy and not stored in the working copy. Only the resulting lock token
and the lock owner (username who created the lock) is stored in the
working copy. The lock owner username is not used for general SVN
authentication, only for authorization of operations relating to that
specific lock.

See also:
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.netmodel.html#svn.serverconfig.netmodel.creds
http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html

> All of the files in .subversion/auth on my workstation and subversion
> server are empty.  I thought those were used for svnserve?

Ah, NetBeans sets it to ${netbeans-userdir}/config/svn/config/auth it seems.
In any case, it's not saved per-working copy.

> Lock Feature test suite doesn't indicate what kind of repository to use.

The kind of repository should not be relevant for this.

> I closed NetBeans, leaving these two projects in the state they were when I
> emailed.
:
> The dialog that opened asking me for user credentials, I supply "user1"
> credentials and get this error in log:
> 
> unlock  /home/leo/workspace/netbeans/test1/Project1/src/project1/Main.java
> Username does not match lock owner
> svn: Unlock of 'Main.java' failed (403 Forbidden)

That seems correct to me, since the lock was created by user2 and you
are trying to unlock it as user1.

> For Lock Features test suite, if I use the same single user credentials to
> lock a file in test case #1, why would test case #4 even have the option to
> "Lock" the same file again?  And Lock it again in test case #5?

It's the same file, but in a different working copy (Project1 vs
Project2). Locks are working-copy specific (by means of the lock token
stored in the working copy). Test cases #3 and #4 are testing that you
can "steal" a lock owned by one working copy to another working copy
using the "force" option.

Test case #5 says "select some Java file" in step 1. It is implicit
that this should be a file that isn't locked yet, although I agree it
would be better if the test case made this explicit. Test case #5 is
testing that the lock is actually doing its job, namely preventing
commits from another working copy to the locked file.

Niklas

-
To unsubscribe, e-mail: netcat-unsubscr...@netbeans.apache.org
For additional commands, e-mail: netcat-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: [vcs] Subversion - Checkout

[Leo Donahue]

Thank you Niklas,

>> SVN does not store the username in the working copy
http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html

The svn redbook seems misleading.
"The fact that the *svn info* command, which does not contact the
repository when run against working copy paths, can display the lock token
reveals an important piece of information about those tokens: they are
cached in the working copy"


All of the files in .subversion/auth on my workstation and subversion
server are empty.  I thought those were used for svnserve?  Lock Feature
test suite doesn't indicate what kind of repository to use.

I closed NetBeans, leaving these two projects in the state they were when I
emailed.

I re-opened NetBeans.

File in Project1 shows "Unlock" in Team menu.  Attempting Unlock says
authentication failed with log message:

==[IDE]== Apr 5, 2018 12:01:27 PM Unlocking Files...
unlock  /home/leo/workspace/netbeans/test1/Project1/src/project1/Main.java
Authentication failed
svn: No more credentials or we tried too many times.
Authentication failed

The dialog that opened asking me for user credentials, I supply "user1"
credentials and get this error in log:

unlock  /home/leo/workspace/netbeans/test1/Project1/src/project1/Main.java
Username does not match lock owner
svn: Unlock of 'Main.java' failed (403 Forbidden)

==[IDE]== Apr 5, 2018 12:09:40 PM Unlocking Files... finished.


Double check (some info redacted):

~/workspace/netbeans/test1/Project1/src/project1$ sudo svn status Main.java
 K  Main.java
~/workspace/netbeans/test1/Project1/src/project1$ sudo svn info Main.java
Path: Main.java
Name: Main.java
Working Copy Root Path: /home/leo/workspace/netbeans/test1/Project1
URL: http://subversion.domain.com/svn/repo1/Project1/src/project1/Main.java
Relative URL: ^/Project1/src/project1/Main.java
Repository Root: http://subversion.domain.com/svn/repo1
Repository UUID:
Revision: 12
Node Kind: file
Schedule: normal
Last Changed Author: user1
Last Changed Rev: 12
Last Changed Date: 2018-04-04 19:40:42 -0600 (Wed, 04 Apr 2018)
Text Last Updated: 2018-04-04 19:42:29 -0600 (Wed, 04 Apr 2018)
Checksum:
Lock Token: opaquelocktoken:
*Lock Owner: user2*
Lock Created: 2018-04-04 19:44:27 -0600 (Wed, 04 Apr 2018)
Lock Comment (1 line):
Lock Project1 Main.java in test1 workspace. No Force.


For Lock Features test suite, if I use the same single user credentials to
lock a file in test case #1, why would test case #4 even have the option to
"Lock" the same file again?  And Lock it again in test case #5?

Before I mark test cases as failed, I want to make sure I am following the
spirit of the test case.

On Thu, Apr 5, 2018 at 7:44 AM, Niklas Matthies  wrote:

> SVN does not store the username in the working copy. Unless a username is
> explicitly specified in an SVN command, SVN uses the last cached
> credentials for the given repository (usually stored under
> $HOME/.subversion/auth on Unix).
>
> After checking out Project1 as user2, the last-cached credentials are
> those of user2, so if you then perform a lock, it uses user2 regardless of
> the working copy.
>
> Niklas
>
>
> On Wed 2018-04-04 at 19:54h, Leo Donahue wrote on netcat:
> > Hi,
> >
> > I have been testing the Lock Feature test suite and noticed some things
> > about the IDE and I'm not sure whether these things contribute to my test
> > cases failing.
> >
> > The setup for Lock Features say:
> > Checkout a Java project using subversion (Project 1)
> > Checkout the same Java project using subversion again into a different
> > directory (Project 2)
> > Two different working copies of the same project should be opened in IDE.
> >
> > The setup does not indicate whether the same project should be checked
> out
> > using different subversion user accounts.
> >
> > I checked out the same subversion project using different user accounts
> > into different workspaces.
> >
> > Project1 was checked out initially as "user1"
> > Project1 was checked out a second time as "user2"
> >
> > When I lock a file in Project1 that was checked out as "user1", the
> > subversion tab says it is locked by "user2".
> >
> > Is that right? It should be locked by "user1".
>
> -
> To unsubscribe, e-mail: netcat-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: netcat-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>

Re: [vcs] Subversion - Resolve conflict - Conflict resolved

[Niklas Matthies]

Sorry for the late reply...

On Thu 2018-03-29 at 20:21h, Leo Donahue wrote on netcat:
:
> Steps from Test case 12. Conflict resolved are confusing - I can't tell
> which project of the three now in project explorer I'm supposed to select
> project root on.

In test suite 3, test case 12, you can actually resuse the second project from 
test case 10 and only re-perform steps 3 and 4 from test case 10. Then in test 
case 12, steps 2 to 4 are performed on the original ("previous" in test case 
10) project, which now has the conflicts just as in test case 11. Test cases 11 
and 12 are basically the same (resolving merge conflicts), only that test case 
11 uses the Merge tool while in test case 12 you resolve the conflicts manually.

Everything going forward in test suite 3 (except test case 16) uses the 
original project, but it doesn't really matter, you can use either. The 
two-project scenario above is only needed for test cases 10 to 12 in order to 
be able to create merge conflicts.

> Test case 13. Delete file also doesn't tell me which project to pick when
> deleting the NewClass.java from package xx.yy. Any of the three projects I
> pick to delete that class did not show the "Locally Deleted" status in the
> Subversion tab.

It does for me when Show Changes was invoked on the project where the deletion 
is made. (The Subversion tab only shows changes for the project(s) on which 
Show Changes was last invoked.)

Niklas

-
To unsubscribe, e-mail: netcat-unsubscr...@netbeans.apache.org
For additional commands, e-mail: netcat-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: [vcs] subversion - delete filed JIRA bug

[David Heffelfinger]

Good question! I filed a couple of bugs to later realize it was user-error
on my part. Couldn't really find a way to delete them.

On Thu, Mar 29, 2018 at 5:35 AM, Leo Donahue  wrote:

> I restarted the Standard Development of Project section and I need to
> delete at least one bug I filed.
>
> In this NetCAT process, to delete a JIRA bug, do we resolve it first and
> then close it, or just close it?
>
> https://issues.apache.org/jira/browse/NETBEANS-545
>
> I was able to make this work the second time.
>



-- 
http://ensode.net - A Guide to Java, Linux and Other Technology Topics
My Books: https://www.packtpub.com/books/info/authors/david-r-heffelfinger

My Video Training:
http://www.packtpub.com/java-ee-development-with-netbeans-7/video
Follow me on Twitter: https://twitter.com/ensode

Re: [vcs] Subversion https protocol

[Leo Donahue]

On Tue, Mar 20, 2018 at 10:54 PM, Leo Donahue  wrote:

> For checking out and importing projects into Subversion using the https
> protocol, if I don't have a Client Certificate File or Passphrase, is that
> acceptable?
>
> If I leave both of those options blank, the checkout/import processes
> still work.
>
> leo
>

Also, the import process of a project with 100 src files takes a noticeable
amount of time after clicking Finish on Step 3 and the status message of
"Committing..." is clearly visible but I never see the "Scanning in
progress" status message.  Does that mean the test fails without seeing
that "scanning" message?