Re: Some of my thought regarding NetCAT 10

[Leo Donahue]

 Good question, I was wondering if we should have been using JIRA labels
for NetCAT 9 and 10 issues.  That would allow you to filter.

On Thu, Nov 1, 2018 at 5:10 AM Geertjan Wielenga
 wrote:

> Is there a way to get a list of all the issues filed through the NetCAT
> program?
>
> Gj
>
> On Thu, Nov 1, 2018 at 9:36 AM  wrote:
>
> > Hello Jiri, hello Alexander,
> >
> > here are my thoughts.
> >
> > > 1. Tickets in strange state
> > >
> > > The luxury of dedicated people paid by Sun/Oracle to pay attention to
> > > bugs, develop features, respond to e-mails and the like are gone. With
> > > the same argument statement "...the dev team cannot address each
> > > issue..." makes no sense because there is no dev team. The dev team is
> > > you.
> >
> > I am afraid I support Alexander here. I bet there are people who have no
> > idea how to code using Java, yet still use NetBeans (e.g. PHP, HTML,
> C/C++).
> >
> > > Complaining about issues being ignored equals showing own
> > > misunderstanding how open source software development works. Good news
> > > is that you can filter the issues reported in October, trying to
> > > reproduce them one by one, adding your investigations and setting their
> > > status and/or priorities correctly. When do you plan to do that?
> >
> > I also got impression (from what I have read on pages dedicated to the
> > process) that we should focus on testing only.
> >
> > But, at the same time, I agree with you, Jiri. If there are no dedicated
> > developers anymore (I mean, people who are actually paid for developing
> > NetBeans), then, solving issues lays on volunteers and I won't raise this
> > kind of objections (not tackling the issues in Jira). Simply, the
> landscape
> > of NetBeans has changed and I need to adapt to it.
> >
> > > 2. Tribe leaders are useless
> > >
> > > I am afraid I disagree. True tribe leaders are precious asset for
> > > NetCAT. They simply act as managers, communicating with their tribe
> > > members, finding their strengths/weaknesses, then distributing the work
> > > load, periodically checking the status/progress, reminding about
> > > incomplete tasks, triaging issues, escalating the most serious ones to
> > > the NetCAT program coordinators, organizing meetups, etc. If these do
> > > not exist, everything falls on plates of NetCAT program coordinators
> > > which are obviously overloaded which leaves NetCAT participants with
> > > impression of chaos, ignorance or frustration.
> >
> > OK, maybe it's still happening, maybe all these activities are still
> > taking place, but, to be honest, I haven't seen that this time that much.
> >
> > I remember older editions of NetCAT, with weekly reports summarizing
> > activities, providing information to whole team, so it knew where it was
> > standing at any, given, time. So, this time, I thought that NetCAT was
> > targeted more towards solo players who want to decide for themselves how
> to
> > update docs, what to choose for testing, etc. Which, in fact, suits me
> > better :)
> >
> > Michal
> >
> > -
> > 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
> >
> >
>

[editor] Appearance

[Leo Donahue]

In my NetBeans 10.0-vc1 (GTK+), I don't see check box outlines, or radio
buttons and on dialogs with scroll bars, those are also not visible (not
shown in this screenshot).

Apache NetBeans IDE Dev (Build incubator-netbeans-release-345-on-20181002)
Debian GNU/Linux 9.5 (stretch)
Linux 4.9.0-8-amd64 x86_64
openjdk version "11.0.1" 2018-10-16

[image: image.png]

Re: Resolving previously failed test cases

[Leo Donahue]

On Fri, Oct 26, 2018 at 7:32 AM Glenn Holmer 
wrote:

> On 10/26/2018 02:55 AM, Leo Donahue wrote:
> > Question:
> > If a test case passes in 10.0-vc1 but there was a bug report for this
> test
> > case in NetCAT 9.0 testing, how should I handle the JIRA?
> >
> > This issue did not occur in 10.0-vc1
> > https://issues.apache.org/jira/browse/NETBEANS-558
>
> I'm not sure if users without admin privileges can remove an issue from
> a test, but I'm making a second pass through all of them to make sure
> the numbers are valid, and to remove those issues marked "resolved
> fixed". This should make it easier for the devs, as they can just click
> the issue numbers to check the reports. If anybody thinks that's a bad
> idea, please speak up!
>
> Looking at 558, it looks like you originally filed it, so you can go to
> JIRA and close it...



>  if it no longer applies. 


Basically I was just asking in general what to do with the existing JIRA
which is documented on a previous NetBeans release.  More specifically,
"resolve" or "close"?

By April of 2019 will anyone care about the JIRA bug documented against
NetBeans 9?  I will be thinking to myself.. should I resolve or close this
or wait...  It may still be a problem on a different environment.
Who decides what is resolved and when?

To me, it seems like the issue should be resolved or closed against the
same code base used when the bug was filed.
Since I don't keep up with the DEV side of NetBeans, maybe I should be, I
don't know what has changed that would give me a passing test case in
10.0-vc1 (which would help me to know what to do with the JIRA).

Ultimately, I don't want to document issues and then hope someone else
figures them out.

Maybe this is more of a JIRA topic that can be discussed and recorded for
those of us who are in different time zones?  Or put some NetCAT JIRA
guidelines on the wiki?


> The old NetBeans Bugzilla had
> lots of stale issues, so let's keep our shiny new Apache JIRA tidy :)
>
> --
> Glenn Holmer (Linux registered user #16682)
> "After the vintage season came the aftermath -- and Cenbe."
>
> -
>

Resolving previously failed test cases

[Leo Donahue]

Question:
If a test case passes in 10.0-vc1 but there was a bug report for this test
case in NetCAT 9.0 testing, how should I handle the JIRA?

This issue did not occur in 10.0-vc1
https://issues.apache.org/jira/browse/NETBEANS-558

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)
>

[vcs] Subversion http:// Test Case

[Leo Donahue]

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)

[vcs] Subversion

[Leo Donahue]

How would I report this:

This is all running on my internal network at home.
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


Test Suite: Setting up URL and content checkout

#2. svn+ssh:// Test Case

I started NetBeans via the command line and when you click "Next", unless
you are paying attention, there isn't a dialog that asks you if you want to
connect to the remote subversion.

You have to say "yes" in the terminal window that launched NetBeans.

If you don't notice your terminal window asking what you want to do, you
wait.. and wait.. and then when you click the "Stop" button that displays
while you are waiting, you have to exit NetBeans to re-enable the "Next"
button.

[image: image.png]

[vcs] NetCAT 10

[Leo Donahue]

I see several threads I could reply to, but I started a new one.

In light of all recent emails about lack of NetCAT 10 volunteers...

Regarding NetCAT 10:

   1. Are there still tribe leaders like in NetCAT 9?
  - All of the recent emails about not being done would have come from
  tribe leaders before.
  2. What NetBeans build does NetCAT 10 require?
  - In NetCAT 9, I saw testers using different Jenkins builds,
  whichever was the latest, and if I remember correctly, we were
supposed to
  stick to specific build number?
   3. What JDK version and implementation does NetCAT 10 require?
  - Oracle or Open JDK?
  4. What constitutes a test spec review?  In other words, aside from
   my input, who else makes decisions on the contents of the test specs?
   - Where do I provide feedback on the VCS Subversion test specs?
  - Does NetCAT 10 test against Subversion 1.9.5 or newer?

I can't find answers to these on the wiki, I thought they were there once
before.

VCS Subversion has roughly 60+ test specs in 9 test suites.
Is the expectation that all 60+ specs are tested separately with: javahl,
svnkit and command line?
In other words, a VCS Subversion volunteer does all 9 test suites
separately using each connector?

Just asking, why VCS Subversion testing in NetCAT 10?
No movement on NetBeans Version Control Issues in JIRAs from previous
NetCAT, so just asking what IDE changes would affect VCS Subversion code
base.
Maybe that is a dumb question, but I honestly don't know.

Leo

incubator build 401

[Leo Donahue]

Thanks!

The Projects and Files tabs are visible.

I don't have to switch to Nimbus look and feel on Linux anymore!

Maybe this change happened before, but I just noticed.

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 <netbe...@nmhq.net> 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

[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 <netbe...@nmhq.net> 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
>
>

[vcs] Subversion - JavaHL

[Leo Donahue]

Debian 4.9.82-1+deb9u3 (2018-03-02) x86_64 GNU/Linux
NetBeans-dev-incubator-netbeans-linux-383-on-20180329-basic

Question:
Is NetBeans supposed to be able to use the svnjavahl.jar from this location:

/home/user/applications/NetBeans-dev-incubator-netbeans-linux-383-on-20180329-basic/netbeans/ide/modules/ext

I am not able to set the Preferred Client from CLI to JavaHL.  I've tried
using the command line switch to force NetBeans to start with JavaHL, but
it still reverts to CLI.

Question:
Can we use subversion 1.9.5 for NetCAT testing or should I have been using
version 1.8?

~$ sudo apt show libsvn-java
Package: libsvn-java
Version: 1.9.5-1+deb9u1
Priority: optional
Section: java
Source: subversion

~$ sudo apt show subversion
Package: subversion
Version: 1.9.5-1+deb9u1
Priority: optional
Section: vcs

[vcs] subversion - delete filed JIRA bug

[Leo Donahue]

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.

[vcs] subversion svn + ssh

[Leo Donahue]

Hello,

I have spent several hours trying to get a connection to Subversion via the
svn+ssh:// protocol.

I finally realized what I needed to change to get it to work.

The screenshots illustrate the error message I was getting.  Then I
realized that the "leo" user was not listed in the
/var/lib/svn/test/conf/authz file.
Adding the "leo" user to authz allowed NetBeans to complete the GUI.

I thought I could connect with one of the dummy accounts in that authz file
(like testuser1), since the id_rsa private key file connects me to the
remote subversion server, but I don't know where to provide that username
and password in this GUI.

Maybe it is not intended to work like that?

Re: [vcs] Subversion https protocol

[Leo Donahue]

On Tue, Mar 20, 2018 at 10:54 PM, Leo Donahue <donahu...@gmail.com> 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?

[vcs] Subversion https protocol

[Leo Donahue]

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

Re: [vcs] We start testing today!

[Leo Donahue]

Can we increase the NetBeans memory for testing or do we have to take the
defaults?

This is really small:  netbeans_default_options="-J-client -J-Xss2m
-J-Xms32m

incubating-netbeans-java-9.0-beta-bin/netbeans/etc/netbeans.conf

On Mon, Mar 19, 2018 at 4:10 AM, David Heffelfinger  wrote:

> Good Morning Version Control Tribe (and others),
>
> I trust all of you had some time to go through your respective test
> specifications.
>
> We are scheduled to start testing today. Those VCS systems where there is
> more than one volunteer (CVS, SVN, and Git), please coordinate among
> yourselves as to how you would like to divide the work.
>
> Please log any issues you find to Jira:
> https://issues.apache.org/jira/projects/NETBEANS/issues/
> NETBEANS-467?filter=al
>
> Let the testing begin! 
>
> David
>
> --
> http://ensode.net - A Guide to Java, Linux and Other Technology Topics
> My Books: http://www.packtpub.com/authors/profiles/david-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] NetBeans Configuration

[Leo Donahue]

Not sure the previous screenshot was attached...  here it is again.




On Sat, Mar 17, 2018 at 4:35 PM, Leo Donahue <donahu...@gmail.com> wrote:

> This is my first time participating in NetCat, so i have a few questions.
>
> Clarification questions:
>
> #1.  We should be testing against the zip file found here:  Yes?
> http://www-eu.apache.org/dist/incubator/netbeans/incubating-
> netbeans-java/incubating-9.0-beta/
> (I ask because I see other tribes talking about certain builds from
> Jenkins)
>
> #2.  Without installing any plugins, should we run "updates" on the IDE
> prior to testing?
>
> #3.  The IDE asks me if I want the nbjavadoc library installed, do I need
> that for testing?
>
> #4.  Do I need to document anything specific about the subversion
> installation I use?
>
>
>