GitEye is a Java GUI client for Git written on top of the Eclipse RCP framework. We are providing downloads for Windows, OSX and Linux though we can theoretically produce builds for a few other operating systems as well if the demand is there. Leveraging the Eclipse RCP framework allows us to provide a native GUI experience on all of these different operating systems, while still benefiting from the cross platform nature of Java. This approach also allows us to leverage a number of existing Eclipse plugins, such as EGit and our own CollabNet Desktop. That said, it is important to note for those that are IDE-averse, that using the Eclipse RCP framework does not mean we are using or repackaging the Eclipse IDE itself. We are simply building this client on the same low-level framework and libraries upon which the Eclipse IDE is built. A framework that we happen to think allows us to build an outstanding and highly functional Git client.

Enough of the low-level details, and more about GitEye. First off, GitEye is a full-featured Git client with all of the options you would expect in a graphical client. Most of the common Git actions are available from the GUI, such as clone, push, fetch, pull, merge, rebase, reset etc. There is a nice graphical view of your History and Annotations and there is a lot of tactical usage of git diff to provide context of changes within the UI as well as a full-blown graphical compare and merge tool. GitEye is a Git client, not an IDE, so the expectation is that you are using other tools and editors to work on your code. GitEye provides a simple text editor for making quick changes, but it also provides context-options to open up your Terminal or native File Manager to the selected location in your file system. You can also define custom commands which allows you to launch other tools. As an example, I work on OSX and use TextMate a lot. So I can right-click on folders or files and open them in TextMate to edit.

If these were all of the features of GitEye, it would be worthy of trying out, but really this is just scratching the surface of what is there. GitEye includes support for GitHub, including Pull Requests, Issues and Gists. All Git clients can presumably clone and push with GitHub, but we go well beyond that in our integration by providing native GUI support for these tools via the GitHub Eclipse plugin. Likewise, we have complete support for CloudForge and TeamForge and the agile planning tools in TeamForge. So besides being able to edit artifacts from within GitEye you can also use tools like the Agile Planning Board and Task Board from TeamForge. The GitHub and TeamForge tools are all built on top of the Eclipse Mylyn framework, so you also have the ability to install support for other trackers, such as Bugzilla, Trac and JIRA from within the application. Additional features that are included are support for Gerrit code reviews and Jenkins/Hudson build monitoring.

Keep your eyes open for future blog posts that describe these individual features in greater detail. Hopefully this was enough to entice you to want to try GitEye. You will be happy to learn that GitEye is Free. Learn more about the features and download it now here: http://www.giteyeapp.com

The post Introducing CollabNet GitEye appeared first on blogs.collab.net.

- TeamForge login: Do you have a long domain name? While we mention that you must use the ‘domain_username’ structure for logging in, what you might not know is that we’ll truncate login names longer than 32 characters. For example: if I have the organization ‘excellentbusinessorganization’ and my username is ‘jesseyowell’, you will see under the TeamForge login page that your login name may be truncated to something like: ‘excellentbusinessorg_jesseyowell’. An easier way to copy your new login for TeamForge can be found under the ‘Services > TeamForge’ under ‘Quick URLs’

- SVN UUID mismatch:  Sometimes you may see an error like this: “Repository UUID ‘xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx’ doesn’t match expected UUID ‘yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy” — This happens when your current local checked out repo doesn’t match the UUIDs on our servers. Maybe you had to move your repository, or create a new one.. whatever the case may be, you can just do a fresh checkout of the repository from CloudForge, and transfer anything you may be currently working on from your old checked out repository.

- “My newly created Subversion/Git repo is still unavailable. I’ve deleted it and now I’m unable to recreate it!” — If for whatever reason your newly created repository isn’t available after 10-15 minutes, please do not delete it! This will create extra deletion jobs and slow down the entire process. Behind the scenes, we have creation / deletion scripts that do a lot of the manual legwork of building and tearing down projects and repositories.

If for whatever reason you are unable to get your new repository running, don’t hesitate and contact support@cloudforge.com right away!

The post Need a quick fix? Simple solutions to SVN, TeamForge and Git appeared first on blogs.collab.net.

% git co branch-1
% (workee workee workee)
% (interrupt)
% git ci -am”Half the change of the primary task”
% git co branch-2
% (workee workee workee)
% git ci -am”The whole change of the interrupt
% git push
babble babble babble
9e7f6d7..35935af branch-1 -> branch-1
ccb352f..66c8c36 branch-2 -> branch-2
Oh no! Not branch1! It’s not finished yet!!!

What Git has just done is technically called “push by matching”: any branches in your repo that have names matching branches in the origin repo get pushed.

The confusing thing here is that some Git commands operate on just the files you have checked out, but others operate on the whole repository. This is particularly confusing (and can be particularly unfortunate) because the very common “checkout,” “pull,” and “commit” commands all operate on “just the checkouts,” but the also very common “push” command is “whole-repository.”

There are reasons for this, some of them good, and with enough practice you can get used to it, and soon you, too, can blithely call stuff like this “the simplest option”:

git push github add-menu:new-feature2

But if you’d like your “simplest options” a bit simpler, or maybe if you think it’s the job of the tool to accommodate the user, not vice versa, then you’re in luck: after a lot of discussion, the git developers have come around to your way of thinking! Git is now being changed to do, by default, what you meant all along.

Since Git was originally released with different behavior — and, indeed, since the original behavior actually does make sense for some users and situations  – the conversion process is rather gradual. With any version of Git after 1.6.3, there’s a new configuration option to control this behavior, and some new messages that hopefully lead you to a resolution. The configuration options are:

Before git version 1.6.3: there are no options, git push does ‘matching’
Beginning in version 1.6.3: You have your choice of nothing, matching (the default), tracking (recommended),  or current
Beginning in version 1.7.4.2: nothing, matching (default), upstream (recommended), tracking (deprecated), or current
Beginning in version 1.7.11: nothing, matching (default), upstream (recommended #1), simple (recommended #2), or current
Beginning in version 2.0: nothing, matching, upstream, simple (default, recommended), or current

What do those options mean?

nothing: Don’t do anything for “git push”; make the user explicitly say what they want pushed
matching: Do that branch-name-matching trick
tracking (later renamed to upstream):  push the current branch to its upstream branch
simple: like upstream, but only if the local and upstream branches have the same name
current: push the current branch to a central branch of the same name (even if they aren’t marked as tracking/upstream)

Which do you use? Most likely either “matching” or “simple”:

If you like the “all branches with matching names” behavior, do “git config –global push.default matching”, and you’ll safely keep doing that even when you upgrade to git version 2.0 (which will have a different default).

If you want to begin living in the brave new world of 2.0, do “git config –global push.default simple”. If you get the error “error: Malformed value for push.default: simple”, your Git is kinda old. The best thing would be to upgrade Git, if you can; otherwise use “upstream” (or even, if you still get the error, “tracking”).

Personally, I’m a simple guy, and “push.default simple” is just what I need. I’m delighted that the community now sees things my way, and I’ve already set this default.

How about you? If you prefer one of the other options, can you explain why? It would be particularly interesting if you can (concisely!) describe a situation that really demands one of the other behaviors. Sound off below.

The post Tips on Git: De-fanging ‘Git Push’ appeared first on blogs.collab.net.

gem install thor interact

Thor is an awesome toolkit for building robust command-line interfaces (CLIs). It’s somewhat similar to Rake but provides more structure specific for DRY command-line scripting. It’s also an essential part of Bundler and Rails under-the-covers.

Interact provides an API for interacting with users beyond simply parsing ARGV. It allows a CLI to ask multiple-choice questions, prompt for passwords, set defaults, and even rewind questions. It is part of the VMC client used to configure and interact with CloudFoundry. The combination of these two gems provides a great deal of flexibility for user-interaction.

My goal in this blog is to create a simple CLI that integrates Thor, Interact and the CloudForge API, making it possible to clone Git repositories by choosing from a list of CloudForge projects.  Git is pretty simple to use as it is but this program provides a good chance to demonstrate these gems and our API. I’ll include a few other gems as well to make things a little easier. I’m also going to start my script with a ruby directive that automatically invokes my script within Ruby when executed.

#!/usr/bin/env ruby
require 'thor'
require 'interact'
require 'yaml'
require 'rest-client'
require 'json'

With my required gems in-place I’m going to start with a simple class method called “config” to save my configuration settings. This will save my CloudForge credentials to a configuration file in my HOME directory so I won’t need to enter them every time.

class CFGit < Thor
  
  # Set up a configuration file so credentials don't need to be entered again.
  desc "config", "configure the domain, username and password"
  option :domain, :aliases => "-d"
  option :username, :aliases => "-u"
  option :password, :aliases => "-pw"
  
  def config 
    # Open a configuration file in the user's home directory
    open(ENV['HOME']+'/.cfgit_config', 'w') do |f|
      # Throw the configuration settings into the fiile using Yaml
      f.write Parameters.new.param_config(options).to_yaml
    end
end

With these few lines Thor automatically creates a ‘config’ command with option flags and provides help documentation.

Thor provides full help context and option flags

This would work as-is except I am calling a “Parameters” class to set my options in my Yaml file. My Parameters class interactively questions the user if any configuration settings are not included.

class Parameters
  include Interactive
  
  def param_config(options)
    
    cf_config=options.dup
    cf_config[:domain] ||= ask "Account Domain"
    cf_config[:username] = ask "Username"
    cf_config[:password] = ask "Password"
    
    return cf_config
      
  end

Now, if I call ‘cfgit config’ I can optionally set my Domain, Username, and Password as command arguments or the program will interactively prompt me to enter them.

Interact prompts the user to enter values for the parameters

This saves my settings into the “cfgit_config” file in my HOME directory. Rather than saving my password locally in the file I created User API Key on my Settings page in CloudForge. This key is used only for API calls and replaces my password. I also want password storage to be optional so I’ll make Password an option for all command arguments.

Now, I want this application to actually do something other than just saving parameters to a file. I’m going to add a “clone” function that will allow the user to select a CloudForge project from a list of all projects, retrieve the ‘ssh’ url for the Git repository in that project and finally clone that Git repository from CloudForge into the present working directory.

First, I need to add a “clone” function to my main Thor class that allows me override any pre-set configuration credentials. i.e. I can skip adding my domain, username, or password into my configuration file and enter them each time I run clone.

# clone a specific repository to the current directory
desc "clone", "clone a repository"
option :project, :aliases => "-p"
option :branch, :aliases => "-b", :default => 'master'
option :domain, :aliases => "-d"
option :username, :aliases => "-u"
option :password, :aliases => "-pw"

	def clone
		# Make sure that all parameters are available
		clone_options = Parameters.new.param_clone(options)

		# get the git ssh url for the selected project
		git_url = CF_Client.git_url(clone_options)

		unless git_url.nil?
  			`git clone #{git_url} -b #{clone_options[:branch]}`
		else
  			puts "This project does not contain a Git repository"
		end
	end
end

I’m still relying on my Parameters class to validate that all of the required parameters are available so I’ll have to add that method to my Parameters class.

def param_clone(options)

	cf_config = YAML::load(File.open(ENV['HOME']+'/.cfgit_config'))
	clone_options = options.dup

	clone_options[:domain] ||= cf_config[:domain]
	clone_options[:username] ||= cf_config[:username]
	clone_options[:password] ||= cf_config[:password]
	clone_options[:project] ||= projects(clone_options[:domain], clone_options[:username], clone_options[:password])
	return clone_options

end

def projects (domain, username, password)

	project_list = ask "Please pick a project",
	:choices => CF_Client.list_projects(domain, username, password),
	:indexed => true

end
end

Just for fun, I added a second method that uses Interact and the CloudForge API to list all available projects as an indexed multiple-choice list. This works when there are few projects available in the account but I wouldn’t recommend it with a long list of projects. My client for the CloudForge API is pretty simple with just two methods:

module CF_Client
  
  DEVORG = 'spiderpig'
  DEVKEY = '1e38bb5ffcf2fc08cff3800eb286fd4eaad60dea'
  URL = "https://api.cloudforge.com/api/1/"
  
  def self.list_projects(domain, username, password)
	projects=[]
	projects = JSON.parse (RestClient.get "#{URL}projects.json", {:params => {"credentials[developerOrganization]" => DEVORG, 
                                    "credentials[developerKey]" => DEVKEY,
                                    "credentials[domain]" => domain,
                                    "credentials[login]" => username,
                                    "credentials[password]" => password}})
    
    project_names = projects.map{|p| p["shortName"]}
	
  end
  
  def self.git_url(options)
    quick_link = nil
    services = JSON.parse (RestClient.get "#{URL}services.json", {:params => {"credentials[developerOrganization]" => DEVORG, 
                                    "credentials[developerKey]" => DEVKEY,
                                    "credentials[domain]" => options[:domain],
                                    "credentials[login]" => options[:username],
                                    "credentials[password]" => options[:password]}})
  
    services.each do |srv|
      if /#{options[:project].to_s}/ =~ srv["accessUrl"]["ssh"] 
        quick_link = srv["accessUrl"]["ssh"]
      end
    end
    return quick_link
  end
end

A multiple-choice list of projects to clone

The last step is to simply choosing project by name or number and it is immediately cloned into my working directory. This application can be easily extended to perform many other features with CloudForge and Git such as “Forking” repositories from one Project to another, creating new Git repositories, or anything else you can think up. I had fun creating this sample application and I hope it helps someone to extend their CloudForge usage or simply start using Thor or Interact.

Below is the full source of this application. You will need to change the DEVORG and DEVKEY constants to your own settings to make it work. If you don’t already have a Git repository on CloudForge click HERE and get started today.

#!/usr/bin/env ruby
require 'thor'
require 'interact'
require 'yaml'
require 'rest-client'
require 'json'


# A chance to use the Thor gem for user interaction
class CFGit  "-d"
  option :username, :aliases => "-u"
  option :password, :aliases => "-pw"
  
  def config 
    # Open a configuration file in the user's home directory
    open(ENV['HOME']+'/.cfgit_config', 'w') do |f|
      # Throw the configuration settings into the fiile using Yaml
      f.write Parameters.new.param_config(options).to_yaml
    end
  end
  
  # clone a specific repository to the current directory
  desc "clone", "clone a repository"
  option :project, :aliases => "-p"
  option :branch, :aliases => "-b", :default => 'master'
  option :domain, :aliases => "-d"
  option :username, :aliases => "-u"
  option :password, :aliases => "-pw"
  
  def clone
    # Make sure that all parameters are available
    clone_options = Parameters.new.param_clone(options)
    
    # get the git ssh url for the selected project
    git_url = CF_Client.git_url(clone_options)
    
    unless git_url.nil?
      `git clone #{git_url} -b #{clone_options[:branch]}`
    else
      puts "This project does not contain a Git repository"
    end
  end
end

class Parameters
  include Interactive
  
  def param_config(options)
    
    cf_config=options.dup
    cf_config[:domain] ||= ask "Account Domain"
    cf_config[:username] = ask "Username"
    cf_config[:password] = ask "Password"
	return cf_config
      
  end
  
  def param_clone(options)
    
    cf_config = YAML::load(File.open(ENV['HOME']+'/.cfgit_config'))
    clone_options = options.dup
	clone_options[:domain] ||= cf_config[:domain]
    clone_options[:username] ||= cf_config[:username]
    clone_options[:password] ||= cf_config[:password]
	clone_options[:project] ||= projects(clone_options[:domain], clone_options[:username], clone_options[:password])
	return clone_options
    
  end
  
  def projects (domain, username, password)
    
    project_list = ask "Please pick a project",
    :choices => CF_Client.list_projects(domain, username, password),
    :indexed => true
    
  end
  
end

module CF_Client
  
  DEVORG = 'spiderpig'
  DEVKEY = '1e38bb5ffcf1ec08daf3800eg286fd4eaad60dea'
  URL = "https://api.cloudforge.com/api/1/"
  
  def self.list_projects(domain, username, password)
	projects=[]
	projects = JSON.parse (RestClient.get "#{URL}projects.json", {:params => {"credentials[developerOrganization]" => DEVORG, 
                                    "credentials[developerKey]" => DEVKEY,
                                    "credentials[domain]" => domain,
                                    "credentials[login]" => username,
                                    "credentials[password]" => password}})
    
    project_names = projects.map{|p| p["shortName"]}
  end
  
  def self.git_url(options)
	quick_link = nil
    services = JSON.parse (RestClient.get "#{URL}services.json", {:params => {"credentials[developerOrganization]" => DEVORG, 
                                    "credentials[developerKey]" => DEVKEY,
                                    "credentials[domain]" => options[:domain],
                                    "credentials[login]" => options[:username],
                                    "credentials[password]" => options[:password]}})
  
    services.each do |srv|
      if /#{options[:project].to_s}/ =~ srv["accessUrl"]["ssh"] 
        quick_link = srv["accessUrl"]["ssh"]
      end
    end
    return quick_link
  end
end

CFGit.start(ARGV)

The post Beginning a CloudForge Git client using Thor and Interact gems appeared first on blogs.collab.net.

Named for the great river Tigris, birthplace of civilizations and stories, the Tigris site provides fertile, well-watered soil for a new kind of community.

A Tigris project collects together the mail lists, wiki, bug tracking, document sharing and storage, and source code — a well-equipped and integrated site for an open-source community.

Membership in the Tigris community is completely free  – and  optional: you can browse around, view, and even download or check out most projects anonymously.  Projects are carefully selected for relevance to the Tigris Mission: Open-Source creation of Software Engineering Tools.

Come visit us: http://www.tigris.org.

If you’d like to host your project here, check out http://www.tigris.org/#start-your-project.

The post Building Open-Source Software Engineering Tools appeared first on blogs.collab.net.

• The Server Status Page (aka status.cloudforge.com):

As you can see in the above picture, we occasionally have to deal with maintenance (and the unfortunate outage…), but I bet you didn’t know that you could subscribe? Simply click on the title of any post and hit ‘Subscribe’ — now you can receive the most recent updates via e-mail…note that this works on any page section on the Help Portal:

Not a fan of receiving e-mail updates?  We also send server status updates via Twitter.. check out CloudForgeOps for any updates.  Have questions, we have answers!

• Feature Requests and Ideas:

We want your ideas!  We definitely have some very good ones brought over from the Codesion days, but we still need your help in determining the next best features on CloudForge.  Be sure to submit and vote on anything you’d like to see!

• For our Business customers.. the VIP section:

This is one of our newest sections just for our Business customers.  Did you know that we have 24/7 phone and live chat support for all Business customers?  We have plans to expand our support for Business customers to be even more robust so stay tuned!  If you happen to be a Business account holder that cannot see this section, please be sure to e-mail support@cloudforge.com.

 Questions? Comments?

If you have any ideas on how we can help you further, give us a shout either through the forums, support@cloudforge.com, or CloudForgeHQ.

The post Help us help you through CloudForge’s Support Portal! appeared first on blogs.collab.net.

The goal of this blog is to compare:  developer start-up time, developer tools, Java & Ruby languages, and Web frameworks.

Developer start up time:

The last two Java web applications I worked on were huge code stacks with Flex UI and an Oracle database.  It took a week to get these applications to run, tweak and break because the setup process required me to install a plethora of tools:  version control, application servers, language packages, databases, and version management systems.

On the contrary, Rails comes pre-packaged with some of the tools mentioned above which reduced my setup time significantly.  It took less than a day on a developer Mac and one day on a brand new Mac.

Developer Tools:

When it was time to look at the code, I was a bit disappointed.  TextMate looked like a popular choice but it fell short in many ways.  I struggled to navigate the code, link the methods across files and follow the code. Grep was my only savior. Some of these might take getting used to, but I did not find anything in the menu that could help. Maybe I am biased, but I miss the intuitive Eclipse IDE and the debugging comfort that allowed me to understand the code better and quicker.
The other developer tools such as database viewer, testing frameworks, and command line interface were pretty much the same, no surprises.

Language

My approach to learning Ruby was to start looking at code and figuring out pieces of syntax that did not make sense.  That turned out to be a bad idea. Constructs like “do |x| x+1” threw me off. It certainly helps when switching languages to map constructs.  However, mapping should only be the initial step to get acquainted.  I found it very important to understand the motivation behind creating the new language.  In the case of Ruby, the reasons I see are to reduce inconsistencies, to minimize verbosity (abstracting/hiding boiler plate code), to simplify complex operations. and to reduce programmer errors.

For example, Java has a concept of primitive data types.  Integer and int co-exist in the language and programmers need to make sure Object versions of these data types are used in the appropriate places.  The language does have warnings/errors in place to help the programmer.  However, a developer should be aware of these aspects.  Ruby eliminates that need since everything in Ruby is an Object including nulls.  Blocks in Ruby simplify iterating and modifying collections among other things.  There is significantly less code to maintain, notably code for parsing files, and code for getter/setter methods.

However, I miss parameters list, curly braces, return statements, camel case naming conventions and one way to declare variables (as opposed to the multiple symbols :, @ in Ruby) that make Java code readable.  The concept of ‘open classes’ that allow developers to go in and change a base class sounds scary.  This means the class I write might operate very differently at a later point and the only way to track it down is by looking at the files history.  It is possible in Java too, but I feel the language protects against it more than Ruby does.

Framework

Frameworks for web applications are probably not too different.  Since the purpose of the framework is same across languages and platforms, the main pieces are similar.  The differences I see are in the amount of automation the frameworks offer.  It helps to start with what makes a web application and what tools a developer needs to get things running.  A web application needs front end/UI code, server code, a web archive of deployed code, application server where the application lives, databases for persisting data, testing framework, a continuous integration system to test, build and deploy code.  Here is my mapping of Java Web application to a Rails app.

In conclusion, Ruby is much more flexible and Rails is a bit more restricted than I am used to.  The restrictions are part of the Convention over Configuration idea.  I need to get use to its various ways and unlearn a lot of Java habits.

How has your transition been? I’d love to know so please share your experiences by entering it in the comment section below.

The post Java Web Apps to Rails, A Developer’s Experience… appeared first on blogs.collab.net.

The first of these changes rolled-out this week on our Dashboard.  Previously, all account owners were presented with an Account Overview at the top of the Dashboard, providing an instant status update of their accounts. Although this Account Overview section could be quickly minimized to bring the Control Panel to the top of the Dashboard, most of our users wanted the Control Panel at the top by default.  Don’t forget, you can completely hide the Quick Start guide once you are familiar with its content.

Now, once the Quick Start Guide has been hidden, the Control Panel owns the top spot in our Dashboard allowing you to quickly and efficiently perform any task on your projects.  The Project List and Activity Feed follow the Control Panel up the ladder to the top of the page giving you a complete view of available actions, projects, and activities in your account.  The Account Overview block remains on the Dashboard (visible only to account owners) but it has moved to the bottom of the page.

At the end of the day, it’s more important to get work done first and then review your account as time allows.  We hope this change makes our site more intuitive and makes you more efficient.

Streamlined Dashboard

The post New Year, New Dashboard Flow appeared first on blogs.collab.net.

Your Activity Stream records significant events, like version control changes, in a real-time historical record that lets you search and filter among entries, and correlate entries of different types, as well as providing hyperlinks to commit details, user profiles, project dashboards, and other related data.  You can find the Activity Stream display on the Dashboard, as well as the specific pages for projects, services, and user profiles.  The latter displays automatically limit response to the ones relevant to that page, but other than that all Activity Stream displays are similar.

If you don’t see the Activity Stream display on your page, ask your administrator to turn on the version control “Users with read access see all commits” feature, or to grant you a role such as Activity Viewer, which includes the “Participation: View Activity” permission.

Wherever you find it, it should look pretty much like this (if you click this image, you should get a larger one in a new window, which might be a useful reference while I explain it).  At the top is a search box, but we’ll get back to that in just a moment. The bulk of the display is a list of activities, or events.  The entries are listed in reverse-chronological order (most recent first), and wherever possible display terms are hyperlinks to further detail.

• The first line is always some sort of identifier for the activity.  In this case, all activities are Git changes, and Git identifies changes with those big, unreadable “hash values” (like “b3640b0fea…”).  Other services have other identifiers.  But, fortunately, you don’t have to read it: just click it, and you’ll go to the appropriate detail page, with more detailed (and more consumable!) information.
• The next line or so is typically some commentary provided by the author, along with the event being described.
• Following that is information identifying the author (click to see their profile), and the project (click for the project dashboard).
• Entries will often include additional info, such as lists of changed files — it all depends on the individual event.

Searching

Now, back to that search box.  Actually, you might want to put this blog aside for just a moment, go to your own Dashboard, and play with searches a bit. You should find a lot of it quite obvious and useful, but you may also find a few cases that don’t do what you expected. That’s the time to come back here for explanations!

Word search

• Type a word into the search box and hit return.  The list will show only entries with that word.  For example, if I search for “merge,” I get this.  Two things are worth note:
  • Not only has the displayed list been shaved down to just the entries mentioning “merge,”
  • but there’s also a new label saying so, and a button to “Clear Results” (that is, to return to the original, full list).

Substring search (the wrong way)

• Notice that the second entry (“fix merge damage”)  is not actually a merge,it only mentions the word.  Let’s restrict the list to actual merges by searching for the sub-string “ranch” (contained in the word “branch”, in all the actual merge events).
  • What do we get? Nothing! What’s up with that?

Wildcard search

• The problem here is that these searches are word searches, not string searches.  While “ranch” is a perfectly fine word, it doesn’t happen to be involved in any of our activities in this project!  What we need is a wildcard search: a search for “*ranch”.  In general:
  • * Means “anything or nothing” (our “*ranch” search would still find the Dude Ranch, if there were one)
  • ? Means “exactly one unspecified character”

Multi-word search

• Some of these merges go into the branch “master”,some come out.  Can we restrict this to just the ones coming out of master?  How about searching for “merge branch master”?  Whoa!  Nope.  That’s not right!  We get back all kinds of things besides the ones we want!
  • The problem here is that what we did was a “multi-word search.”  That’s interpreted as “show me every activity that includes any of these words.”  This is sometimes useful, like if you should wonder “Was that file named foo? or fu? or fyu?”

Phrase search

• But what we really want here is the phrase ”merge branch master,” not merely “any one of those words.”  There’s a way to do that, by quoting the phrase:
  • Search for “merge branch master” (with the quotes)
  • Now we get the list we wanted
  • Notice also that the apostrophes around master (in the results) do not interfere. Again, this is a word-search system; punctuation need not apply.

So, there you have it: a handy, searchable, real-time record of what’s happening in your organization!

How can you put it to work?

The post Making the Most of your Activity Stream appeared first on blogs.collab.net.

http://help.cloudforge.com

The new, enhanced support portal is a significant improvement over our old forums, providing clean simple ticket system. The new portal includes many of the same great features you experienced in the past & in addition also gives you greater flexibility, richer knowledge base articles and insight into your support cases.

Added Benefits and Improvements to the Support Portal include:

• Real-time visibility (status) and tracking of your case through Mobile app
• Advanced search capabilities across different knowledge bases
• Ability to add cases through Social tools like twitter & Facebook
• New feature request forum with ability to vote on popular product suggestion

Important Updates:

• With the new customer portal your login information will be the same as your CloudForge login
• The new Portal will be for all new issues and cases.
• Your old support cases will be maintained in the old system for 2-3 months.
• You will be able to access this portal from the new one via web links.

We would love to hear what you think of the new Support portal so feel free to drop us a line.

support@cloudforge.com

The post New CloudForge Support Portal! appeared first on blogs.collab.net.