This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 234836 - NetBeans should provide some simple wildcard filters relating to projects
Summary: NetBeans should provide some simple wildcard filters relating to projects
Status: NEW
Alias: None
Product: php
Classification: Unclassified
Component: Project (show other bugs)
Version: 7.4
Hardware: Macintosh Mac OS X
: P3 normal (vote)
Assignee: Tomas Mysik
Depends on:
Reported: 2013-08-23 08:06 UTC by phpguru
Modified: 2013-08-23 20:25 UTC (History)
1 user (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description phpguru 2013-08-23 08:06:01 UTC
Originally I was going to file this as a bug in Subversion: 

NetBeans needs [an option] to include invisible folders when creating project from remote sources

but as I thought about it, I think it's a larger issue.


NetBeans is very particular about the order in which you perform the steps to create a new project... especially when you have to run your project on a remote server. 

I am coming into a project that is already under revision control, and already checked out from SVN on my remote server, where I've already made many changes.

If I use Team Checkout, it creates a working copy on my local machine that is quite likely older than the working copy I have on the remote server, and I'm afraid I may overwrite my changes on remote server when syncing or creating the project or uploading it the first time.

If I do not use Team Checkout, but instead choose to create the project as from remote server, (this is arguably a bug) NetBeans ignores .svn folder(s) on the remote server, and thus I can't make changes and commit them now that I have them locally, without svn checkout somewhere else on my machine and diff/rsync the .svn folders into it. Or, I have to go find some other tool, or use scp, rsync or sftp outside of NetBeans to fetch the .svn directories NetBeans just ignored in my remote server.

I feel I should not need any separate program (terminal, ssh, tar, gzip, scp, rsync, sftp, etc) in order to ensure that 100% of my remote site files are downloaded when creating a new project based on a remote server.

What I expected was that, NetBeans would download .svn folders, and I would instantly gain the benefit of seeing which files are new (green) and modified (blue) -- however none of this info is here after I waited for NB to create my local project based on remote server sources.

It would be my desire that you could add a this checkbox to the create project from remote sources:

[x] Download hidden files/folders

(checked by default)

or just download everything on my remote server path without adding that option at all. 

Or, even better I think, an enhancement feature, to provide a field associated with the project where I can enter 

File Transfer Ignore File Folder patterns...


etc. This way I could delete .svn and .git from this box and expect to receive my project files downloaded locally with Subversion/Git integration intact and all my changes ready commit. This option needs to become a new step in the create project from remote sources flow.

It follows that, for each line on this list of things to ignore during file transfers, NetBeans could offer to make those same items ignored in my VCS system and set the appropriate .gitignore or svn propset svn:ignore accordingly.
Comment 1 Ondrej Vrabec 2013-08-23 10:44:32 UTC
I assume you're talking about PHP FTP support?
Well, from your post i got the impression you're accessing remote files with two different channels: either via FTP or via version control. That's simply wrong and almost a stupid idea. I can barely understand the scenario with getting sources via version control from one server and upload them on save to another via FTP but having just one remote location and downloading/uploading the files with either VCS or FTP is really something i cannot grasp. The correct way to get files to your local machine is always via version control only when the project is already versioned.
But passing to php owners to decide what to do with this request.
Comment 2 phpguru 2013-08-23 20:25:31 UTC
I use PHP NetBeans, but I assume the process of creating a new site [either from SVN via team checkout or via download from remote] is quite similar regardless of the server side language being used.

Having said that I agree that VCS should always be the go-to for first checkout and creating a project.

But, in the case I describe, my "remote server" is a development server on which I have been performing changes using vi on the server over SSH. 

Now then, all I am really saying here is that if NetBeans were to simply download .svn folders (or .git folders, or other invisible files crucial for VSC system operation) then all would be good in the world, because NetBeans would just read the .svn info as it would do if I tar gzip'd the whole thing and downloaded it and made it a new project from existing sources.

It is easily conceivable that my dev server has a working copy and relates to the run configuration, and that I have a working copy on my local machine, and that both my dev server and my local machine are able to access the SVN repo, is it not?

In short, if NetBeans downloaded invisibles from remote, it would be better than it is now. If it had filter patterns to include or not include when downloading remote files for inclusion in the project and it observed the invisible files on a remote server, it would be more flexible for use cases you can barely conceive of, and in theory be easier to set up a new project.

What I am forced to do now, given the methods currently provided in NetBeans, is SSH to the dev server, commit everything there using CLI tools (often painful, particularly if the commit fails due to conflicts), then create a new project that is unaware of the remote site using Team Checkout feature, then pushing all of the exact same files back to the remote server. 

I hope this explains why I don't think it is a stupid idea.