Sparse Directories, Now With Exclusion
If I had a dollar for every time I've typed that… well, you and I could at least spring for some Fazoli's fast-food Italian. Okay, I admit that the emotion doesn't always drive me to public expression, but that in no way diminishes my fondness for this feature.
Introduced in Subversion 1.5, sparse directory support is one of a few features from that release (besides merge tracking and foreign repository merges) that I've fully integrated into my day-to-day activities. I dig organization. I tend to keep a pretty neat home directory. But I routinely work on several different pieces of software, and at any given time, I'm tracking several different development branches in each of those pieces of software. Were I not using sparse directories, my "projects" directory would look something like this:
$ ls ~/projects
subversion/ svnbook/ viewvc-1.0.7/
subversion-1.5.x/ thotkeeper/ viewvc-1.0.x/
subversion-1.6.x/ thotkeeper-0.3.0/ viewvc-1.1.0-beta1/
subversion-http-protocol-v2/ viewvc/ viewvc-1.1.x/
$
On the positive side of things, I could quickly update all my working copies by simply running svn update ~/projects/*.
But those of you who have command-line completion as hard-wired into your habits as I do will immediately notice that so many common directory prefixes does a useless completion environment make. And not using common prefixes? Well that's just barbaric.
Fortunately, sparse directories has given me a whole new perspective on working copy organization. Now, my projects directory contains (gasp!) only projects, and looks like this:
$ ls ~/projects
subversion/ svnbook/ thotkeeper/ viewvc/
$
Those directories are sparse checkouts of the root directories of their respective project repositories. Beneath them are (at least) "trunk" directories, probably "branch" and some of its children, and maybe even "tags" with some of its children in certain cases. svn up ~/projects/* still works, and my working copy topology matches that of the repositories.
I won't go into the details of how sparse checkouts works here — I've already documented the Subversion 1.5 implementation of them in the second edition of Version Control With Subversion (which you can read at http://svnbook.red-bean.com/en/1.5/svn.advanced.sparsedirs.html). The point of this blog post is to tell you about how Subversion 1.6 improves this feature in a key way.
In Subversion 1.6 (slated for release Any Day Now), the --set-depth parameter to svn update has grown a new value — exclude. This value tells Subversion to exclude the target from the working copy, immediately and until further notice. Prior to Subversion 1.6, if a branch I was working on was no longer of interest to me, I couldn't easily remove it from my working copy. If I simply deleted it, it would return the next time I updated the working copy. If I svn delete'd it, the branch remained as a local modification forever. (Unless, of course, I accidentally committed it, which brought a whole different sort of trouble to my doorstep. Angry peers. Pitchforks and torches. It was a mess — you don't want to go there.) The new exclusion mechanism in Subversion 1.6 is the Right Way To Do It.
Say I no longer care about what's going on some directory of one my project working copies. Maybe I don't care about the Subversion project's website any more. Well, with this new exclusion feature, I can tell Subversion to remove that directory:
$ cd ~/projects/subversion/trunk
$ svn update --set-depth=exclude www
D www
$ ls www
ls: cannot access www: No such file or directory
$
Done deal. When I update my working copy in the future, I will not receive any changes aimed at that www directory. If I later decide that I once again care about that directory, I can "resubscribe" to it again:
$ svn update --set-depth=infinity www
A www
A www/links.html
A www/testing-goals.html
…
A www/tigris-permissions.html
A www/webdav-usage.html
Updated to revision 36292.
$
Note that if you exclude a versioned directory that has some unversioned files in it, or some files with local modifications, Subversion handles this situation gracefully. All the files that aren't safe to delete, Subversion leaves around, and of course leaves any intermediate directories required to reach those files, too.
I hope this enhancement serves you as well as it has served me. What do you think? How are you using sparse directories to better organize your life?
Thursday, August 26, 2010
Sunday, March 28, 2010
How to config Java WebStart to use logging subsystem
I am using for client side slf4j as facade framework but behind we decided to use jdk14 standard logging. SO to config jdk14 for webstart you need to
do following:
1) Define according your OS platform JAVAWS_VM_ARGS environment variable, for linux its like this:
export JAVAWS_VM_ARGS="-Djava.util.logging.config.file=/home/sargis/<localpath>/logging.properties"
2) Here is logging.properties content:
handlers= java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.level = ALL
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
.level= INFO
info.sargis.level = FINE
info.sargis.handlers = java.util.logging.ConsoleHandler
Monday, December 21, 2009
Can I run NetBeans with a custom Look and Feel (laf)?
Yes. You can switch the look and feel (laf) of NetBeans to any of the following widgets: (Screenshots)
Available Themes
- Metal: Also known as "Cross Platform Look And Feel" or "Ocean theme". The typical Java look - this is the default. This class is part of the Java Runtime as javax.swing.plaf.metal.MetalLookAndFeel.
- Nimbus: A modern Synth-based laf. This class is part of the Java Runtime 6u10 as com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel.
- Native: Also known as "System Look And Feel". These classes are part of the Java Runtime ascom.sun.java.swing.plaf.windows.WindowsLookAndFeel (MS Windows), or com.sun.java.swing.plaf.gtk.GTKLookAndFeel (Linux), orcom.sun.java.swing.plaf.mac.MacLookAndFeel (Mac OS) depending on the operating system you use (See alsoUIManager.getSystemLookAndFeelClassName()).
- Motif: A classic laf. This class is part of the Java Runtime as com.sun.java.swing.plaf.motif.MotifLookAndFeel.
- ... or choose a third-party laf such as Substance ( more...), Napkin, Synthetica, TinyLaF, JGoodies Plastic, and many more. Note that NetBeans is not being regularly tested with alternate/third-party look and feel implementations. Various implementations may or may not work well.
Activating a Theme
Follow these steps to try out different lafs:
- Decide which Look and Feel widget you want (see list above) and remember it's class name (<laf_class>).
- If it's a third-party widget, download the JAR file containing the custom laf classes (<jar_path>).
- Start NetBeans from the command line with the following options (cf. examples below):
- If it's a third-party widget, place the JAR in the classpath using the --cp:p <jar_path> start-up option.
- Select the laf using the --laf <laf_class> start-up option.
- When NetBeans starts you should notice the different look. If not, check for typos.
- If you like the theme, make your custom start-up parameters permanent.
Original link: http://wiki.netbeans.org/FaqCustomLaf
Friday, December 11, 2009
Seam contextual events
Found nice link related to Seam framework contextual events, here is list:
Seam defines a number of built-in events that the application can use to perform special kinds of framework integration. The events are:
org.jboss.seam.validationFailed — called when JSF validation fails
org.jboss.seam.noConversation — called when there is no long running conversation and a long running conversation is required
org.jboss.seam.preSetVariable.<name> — called when the context variable <name> is set
org.jboss.seam.postSetVariable.<name> — called when the context variable <name> is set
org.jboss.seam.preRemoveVariable.<name> — called when the context variable <name> is unset
org.jboss.seam.postRemoveVariable.<name> — called when the context variable <name> is unset
org.jboss.seam.preDestroyContext.<SCOPE> — called before the <SCOPE> context is destroyed
org.jboss.seam.postDestroyContext.<SCOPE> — called after the <SCOPE> context is destroyed
org.jboss.seam.beginConversation — called whenever a long-running conversation begins
org.jboss.seam.endConversation — called whenever a long-running conversation ends
org.jboss.seam.beginPageflow.<name> — called when the pageflow <name> begins
org.jboss.seam.endPageflow.<name> — called when the pageflow <name> ends
org.jboss.seam.createProcess.<name> — called when the process <name> is created
org.jboss.seam.endProcess.<name> — called when the process <name> ends
org.jboss.seam.initProcess.<name> — called when the process <name> is associated with the conversation
org.jboss.seam.initTask.<name> — called when the task <name> is associated with the conversation
org.jboss.seam.startTask.<name> — called when the task <name> is started
org.jboss.seam.endTask.<name> — called when the task <name> is ended
org.jboss.seam.postCreate.<name> — called when the component <name> is created
org.jboss.seam.preDestroy.<name> — called when the component <name> is destroyed
org.jboss.seam.beforePhase — called before the start of a JSF phase
org.jboss.seam.afterPhase — called after the end of a JSF phase
org.jboss.seam.postAuthenticate.<name> — called after a user is authenticated
org.jboss.seam.preAuthenticate.<name> — called before attempting to authenticate a user
org.jboss.seam.notLoggedIn — called there is no authenticated user and authentication is required
org.jboss.seam.rememberMe — occurs when Seam security detects the username in a cookie
Seam components may observe any of these events in just the same way they observe any other component-driven events.
And original link: http://www.redhat.com/docs/manuals/jboss/jboss-eap-4.3/doc/seam/Seam_Reference_Guide/html/Seam_Reference_Guide-Seam_events-Contextual_events.html
Seam defines a number of built-in events that the application can use to perform special kinds of framework integration. The events are:
org.jboss.seam.validationFailed — called when JSF validation fails
org.jboss.seam.noConversation — called when there is no long running conversation and a long running conversation is required
org.jboss.seam.preSetVariable.<name> — called when the context variable <name> is set
org.jboss.seam.postSetVariable.<name> — called when the context variable <name> is set
org.jboss.seam.preRemoveVariable.<name> — called when the context variable <name> is unset
org.jboss.seam.postRemoveVariable.<name> — called when the context variable <name> is unset
org.jboss.seam.preDestroyContext.<SCOPE> — called before the <SCOPE> context is destroyed
org.jboss.seam.postDestroyContext.<SCOPE> — called after the <SCOPE> context is destroyed
org.jboss.seam.beginConversation — called whenever a long-running conversation begins
org.jboss.seam.endConversation — called whenever a long-running conversation ends
org.jboss.seam.beginPageflow.<name> — called when the pageflow <name> begins
org.jboss.seam.endPageflow.<name> — called when the pageflow <name> ends
org.jboss.seam.createProcess.<name> — called when the process <name> is created
org.jboss.seam.endProcess.<name> — called when the process <name> ends
org.jboss.seam.initProcess.<name> — called when the process <name> is associated with the conversation
org.jboss.seam.initTask.<name> — called when the task <name> is associated with the conversation
org.jboss.seam.startTask.<name> — called when the task <name> is started
org.jboss.seam.endTask.<name> — called when the task <name> is ended
org.jboss.seam.postCreate.<name> — called when the component <name> is created
org.jboss.seam.preDestroy.<name> — called when the component <name> is destroyed
org.jboss.seam.beforePhase — called before the start of a JSF phase
org.jboss.seam.afterPhase — called after the end of a JSF phase
org.jboss.seam.postAuthenticate.<name> — called after a user is authenticated
org.jboss.seam.preAuthenticate.<name> — called before attempting to authenticate a user
org.jboss.seam.notLoggedIn — called there is no authenticated user and authentication is required
org.jboss.seam.rememberMe — occurs when Seam security detects the username in a cookie
Seam components may observe any of these events in just the same way they observe any other component-driven events.
And original link: http://www.redhat.com/docs/manuals/jboss/jboss-eap-4.3/doc/seam/Seam_Reference_Guide/html/Seam_Reference_Guide-Seam_events-Contextual_events.html
Friday, June 6, 2008
Look for cursors which are open
When you perform tests, there is a basic query you can use which will look for cursors which are open. You will want to use this:
select s.SQL_TEXT , count(*) from v$sql s, v$open_cursor oc
where oc.hash_value = s.hash_value
group by s.SQL_TEXT having count(*) > 1
select s.SQL_TEXT , USER_NAME, count(*) from v$sql s, v$open_cursor oc
where oc.hash_value = s.hash_value and USER_NAME='EPSO'
group by s.SQL_TEXT,USER_NAME having count(*) > 1
The query will tell you exactly which cursors are open. If certain cursors are not closed, the count for these queries will continue to increase. After you've found the query, fixing the code will be simple. The next thing you will want to pay attention to is CPU queries. One feature you can use to look for CPU queries is called the V$sqlarea view. It features a number of columns which will allow you to find queries which are memory intensive. The CPU_TIME feature will determine the number of microseconds that the SQL uses for parsing and execution.
Don't remember original source of this info :-(, I hope author will forgive me
select s.SQL_TEXT , count(*) from v$sql s, v$open_cursor oc
where oc.hash_value = s.hash_value
group by s.SQL_TEXT having count(*) > 1
select s.SQL_TEXT , USER_NAME, count(*) from v$sql s, v$open_cursor oc
where oc.hash_value = s.hash_value and USER_NAME='EPSO'
group by s.SQL_TEXT,USER_NAME having count(*) > 1
The query will tell you exactly which cursors are open. If certain cursors are not closed, the count for these queries will continue to increase. After you've found the query, fixing the code will be simple. The next thing you will want to pay attention to is CPU queries. One feature you can use to look for CPU queries is called the V$sqlarea view. It features a number of columns which will allow you to find queries which are memory intensive. The CPU_TIME feature will determine the number of microseconds that the SQL uses for parsing and execution.
Don't remember original source of this info :-(, I hope author will forgive me
Subscribe to:
Posts (Atom)