We Keep Coding

Sending last version from SVN to Tomcat6 webapp directory

Well, I have a SVN Server where is all my application, my doubt is very simple but i can't find any good answer in internet. I want to know if have some way to automatic "copy" the last version of SVN Trunk TO my /var/lib/tomcat6/webapp/myproject/.
So, i want to make this "copY" only when is needed, i.e: all the night i can't configure the crontab to make this copy for me.

I do not know whether I got your question or not. But if you want to update your workspace project from svn you can update like following:
Use svn software like: TortoiseSVN. Download from Here. And Install in your computer.
Right click selecting your project and there is option svn...and you will find update option
. Click update your project will be updated from svn.
If you want to copy all file form your trunk you can also
checkout project from svn clicking checkout option which is available in TortoiseSVN.
If you are using netbeans ide you can also do from there.
a: First you can checkout (if you want to copy all file) STEPS : Go to Team --->Sub Version--->checkout
b: Second if you had already checked-out STEPS: Select your project--->Right Click ---> Sub Version --->Update. It will update all from svn.

Using Eclipse with Subversion and Maven

I am trying to use Eclipse, Subversion and Maven for my projects and everyone is telling me never to check in the following files:
target/
.classpath
.project
.settings
But if I dont check them in and some other project checkouts the project from within Eclipse, Eclipse does not know what type of project it is.. Are we doing something wroung?
How do you work?

Eclipse has a plug-in for Maven; I believe it is called m2eclipse. After having it installed you can select Import from Maven project and select the pom.xml which will import your project to eclipse even if .project and .settings are not present. So there is no need for you to commit them to svn. This comes with the advantage of IDE neutrality; other members of your team may use Intellij IDEA or NetBeans without any concern.
Also Maven has a plug-in for eclipse; you can go where pom.xml is located, open a terminal and type mvn eclipse:eclipse and it will automatically generate .project and .settings.. However the first option is more recommended.

I had the same issue with eclipse, maven and git, so maybe it is helpful for you:
Try to setup your repo in svn and check it out, but don't import it.
You have to import the project over File -> Import -> Existing Maven Project into your workspace.
The last step is to share the project. Rightclick -> Team -> Share -> SVN -> and set the existing one as repo.
That's the way I handle this in Eclipse. Hope it's clear enough?
Btw you should not check in these file, because classpath and so on could be different on other machines.

I check in .classpath and .project but not very often. You do have to make sure that everyone who is working on the project has versions of eclipse that are close enough (including the particular plugins and eclipse features included). Sometimes you can get by with very different versions of eclipse if you make sure almost nobody checks those files in and everybody just mostly compares and manually updates those files from the version control when they are updated.
If you don't check them in, everybody has to create an empty project and then load the source files (and all the version control files or folders) into the project. If you are careful you can copy in those two files and then fool with the options settings to make them match.
Note that Maven helps a lot with this as it takes care of most of the content of the .classpath file.

The main reason not to check in those files are that the IDE's will very likely make changes to those files to suit your local dev environment. Which will probably cause conflicts and thus "broken" projects if everybody is committing their versions all the time.
That said, eclipse should have decent maven integration via the m2eclipse plugin (which I believe might be baked in by default these days).
Part of the idea behind Maven is exactly this - reproducible builds cross platform, cross IDE etc etc - so IDE specific files like that should not be required to build the project.
Importing the project with the m2eclipse plugin should sort things out nicely.

If you mean the other members check out the project and it doesn't work for them, they can check out the maven project separately without using eclipse and then import it into eclipse as an existing maven project using the m2eclipse plugin. This works cleanly without any problems (for me at least).

if everyone in your team is using Eclipse and it is agreed that the project will never use anything else, you may as weel check those files in. but it will make things kind of irritating if someone uses IntelliJ, Netbeans of other tooling or has his Eclipse very customized.

It depends.
Maven documentation explicitly says something like "Do not check in .project/.classpath/.settings/ because they can be regenerated from pom.xml". The later part of the sentence ("they can be regenerated") is not true, so the first part of the sentence (the advice) may or may not be OK, depending on the circunstances. Not every bit of the Eclipse configuration can be regenerated from the pom.xml, so my opinion is that the decission is based on a tradeoff between how much gain you get from it and being tied to the particular IDE.
So it depends.
For "community projects", where usually each developer will use different IDEs and different versions of the IDE, I would recommend not to check in those files. Otherwise, it would be a pain for developers not using your IDE and your version of the IDE.
For large "corporate project", IDE and IDE version are not free to be choosen by the developer but firmly dictated by the project management. So are dictated things such as compiler(1), code formatting, validating rules, warnings-and-errors configuration, custom in-house plugins configuration and many others. Many of those things cannot be set in pom.xml (nor should they because Maven is not and IDE, but a building tool). So in this case I would recomend to check in those files and blame the developer who complies, because he is trying not to follow the dictates.
(Notice that in this case I intentionally used words such as "dictate" and "blame" because the project management of a corporate project has not only the right but also de duty to "dictate" and "blame")
In the opposite side, for one-person projects, you do not have to worry about your colleages, so go check them in.
But the key is that you have to know your circunstances and the consecuences and decide yourself.
(1) No, "maven.compiler.source" is not the compiler to be used.

Adding 3 projects to version control (SVN) in Eclipse

I'm currently developing an application, and I have worked in the last weeks with the following 3-project setup :
the code itself;
unit tests;
acceptance tests.
Until now, I had only the code itself under version control. I'm researching on how to include all the 3 projects under version control. I'd like to have everything under the same repository. I've created 3 folders(one for each project) under my SVN repo.
In a new workspace, I've imported each one of the projects into Eclipse. This seems, at first, to be working fine, but I'm not sure if I won't get problems later on when trying to make commits to the server and the different projects aren't in the most recent update.
I'd guess this wouldn't be a problem as they don't share any file, at all, but I'm not really sure. Is this the correct approach for the given situation? How would you handle this?

You create a local project in Eclipse, right-click on it, and select Team/Share project...
Then a wizard will guide you, and allow putting the code into the correct folder of the svn server.

How to read SVN Tortoise Command from Java application

As I am doing an application which requires to do all the operations like checkout, checkin, commit, rollback and etc.. Please can any one give command line options for SVN tortoise?

As I understand, you want to implement a Java application that calls Subversion commands. I think there are 3 options you could go with:
(and best one): Use SVNKit as a pure Java implementation of the Subversion API in Java. So you have there Java classes and methods and can do anything you want (if you understand how to use it correctly).
You could use JavaHL which is more difficult to install, but then comparable in usage to SVNKit. However, the implementation differs on different platforms (no Java-only implementation), so depending on your usage scenario, it may not be an option.
You could just start svn commands from Java, but I would not do that.
There is enough information available on the internet how to do the base commands with SVNKit, so just give it a try.

TortoiseSVN is a front end to subversion. See the Version Control with
Subversion book for a list of all the command line commands. Appendix E. Command Line Interface Cross Reference of the TortoiseSVN documentation provides another source for the commands.

You will get enough help from internet about tortoise SVN.
You can create a repository in system folder or in Eclipse.
These steps will install SVN plug-in in Eclipse.
Open Eclipse.
Go to Help Click Install New Software
Click “Add” button
Put “Subclipse 1.2.x (Eclipse 3.2+)” under Name and “http://subclipse.tigris.org/update_1.8.x” under Location:
Click ok
Select subclipse selection option in selection window. Select all
Click next button n/a
In review the items to be installed window. Click next.
Licenses must be reviewed and accepted before the software can be installed. Click I accept radio box. Click finish.
During installation eclipse may ask for the validity of plugin being installed. Click ok
After installation. Restart Eclipse.
Create SVN Repository Location in Eclipse
In the navigator perspective, right click and choose new
Choose SVN > Checkout Projects from SVN
Select the option to create a new repository location.
Fill in the location of the SVN repository (https://link-to-repository) and click next. Project info is loaded.
It may ask username and password or validation of repository site certificates. Click “accept permanently”.
From RAD File menu, choose Import to display the import manager. Choose Checkout Projects from SVN. Click Next
Select Use existing repository location option to enable the Next button.
It will load all projects from repository in “trunk”. Expand trunk menu option
Select all the projects one by one to import in projects in workspace.

Why would you not call svn commands directly from java? I mean can't we open a command prompt using a RunTime instance and passing the svn command to it.Is that a bad idea?If yes, what are the disadvantages?

Getting Netbeans and Subversion to play together nicely with libraries?

I'm having a difficult time figuring out how to add a .jar/library to a Netbeans project in such a way that I can get it committed to the repository.
The typical way to add a library (per the Netbeans documents I've already gone through) ends up with it just being local to me. Anyone who checks out my project ends up missing my required library.
Inserting it manually and trying to work around Netbeans results in Netbeans hanging while trying to scan the project...
So, how can I tell Netbeans to pick up a jar as a library and include it in my project in such a way that Subversion will be able to handle it?

There are a couple ways to fix this.
A. When you define your Library, use a path to a common location. A location that's identical on everyone's machine--such as the location of a JAR installed with a third-party app into Program Files or /usr/local/ works well or a network drive.
Then, when they check-out the code, the path will still be correct and they do not have to define the Library on their Netbeans workspace.
B. Edit your project.properties file to use a relative path. Open your project.properties file and look for "libs.LIBRARY_NAME.classpath=...". That will be the "default" location used if the Library is not defined.
Change this to use a path relative to your project and store the jar files in your project. For example:
libs.Log4J.classpath=lib/log4j.jar
Keep in mind that the Library definition in your Library Manager will override this value--so make sure you keep them in-sync (i.e. append a version number to the library name!).
C. Use Vincent's suggestion of using a build-system such as Maven. The Maven build-process will take care of downloading dependencies, etc. Netbeans has plugins for several popular build systems.

There is a new feature in NetBeans 6.5 (variable-based paths in projects) which should make this easier.
See http://wiki.netbeans.org/NewAndNoteWorthyNB65#section-NewAndNoteWorthyNB65-VariableBasedPathsInJ2SEJ2EEProjects for details. Note the screenshot includes variable references in the library customizer.

Not really an answer to your question but... generally you should not include these libraries in your subversion repository. There is usually no need to have them managed. What you might want is to set up a central repository similar to what happens with maven. If you use maven, you can create a local repository of libraries on a server accessible by the team. The dependencies on these libraries are entered in the pom.xml file and this is in the subversion repository. Now, as team members check out the code from subversion they all have access to the maven repository.
[I am looking for a reference to this right now. When I find it I'll edit this answer.]

I use NetBeans IDE 6.5.1 and the best solution I've found so far is to include the needed libraries from your local host and then change their paths to relative. After that you have to remove the libraries manually from the NetBeans file explorer, and then copy them from their OS location in your computer manually to the file explorer again. That way NetBeans detects the change and you can commit it to the repository.
Note: I Highly recommend to clean and build the project again after updating.

An easy way to pack up your lib/jars into your project so that subversion "just handles it" so you can grab it out with all the attached libraries ready to compile and go is to include them all under your project directory via the "shared libraries" option by managing the libraries folder.
When creating a new project you can specify "Use Dedicated Folder for Storing Libraries" and then use the suggested relative .\lib path. If you have an existing project, you can edit it's properties, Libraries Category, and Browse for a Libraries Folder. Again a first-time run will suggest .\lib and then offer to copy existing dependencies to that folder. These graphical actions should provide similar results to James Schek's 'B' answer.
Commit the project with the newly added libs in .\lib and you should be able to checkout and build from anywhere and know you'll have the same libs (at the same version) as you had when you last built and committed.
I don't know how long this feature has been in NetBeans. For more details see:
http://netbeans.org/kb/docs/java/project-setup.html#projects-shared-libraries

I ended up just downloading my own set and putting them on my local drive for this project. I setup my Netbeans to look there and warned the other guys what I did... Eventually, we'll have to do something a bit more scalable though... :-)

OK, the working solution that I've now moved to is to extract the class files out of the jars and dump them into the Source Packages area. Then it all gets committed to the repository and also avoids having to deal with handling a separate "lib" directory in the deployment phase.
This solution does everything I'm looking for, yet I feel real dirty about doing it this way. It just seems horribly broken and wrong... :-)