Top Questions on Stack Overflow

List of Tags
140
Thelema

I have a complex command that I'd like to make a shell/bash script of. I can write it in terms of $1 easily:

foo $1 args -o $1.ext

I want to be able to pass multiple input names into the script - what's the right way to do this? Of course I want to handle filenames with spaces in them.

Answered By: Robert Gamble ( 210)

Use "$@" to represent all the arguments:

for var in "$@"
do
    echo "$var"
done

This will iterate over each argument and print it out on a separate line. $@ behaves like $* except that when quoted the arguments are broken up properly if there are spaces in them:

sh test.sh 1 2 '3 4'
1
2
3 4
140
Robert Dean

I'm new to svn and I'd like to know what are common methods of backing up repositories in a windows environment?

Answered By: Nicolai Reuschling ( 131)

You could use something like (Linux):

svnadmin dump repositorypath | gzip > backupname.svn.gz

Since Windows does not support GZip it is just:

svnadmin dump repositorypath > backupname.svn
140
user18931

I want a true deep copy. In Java, this was easy, but how do you do it in C#?

Answered By: Kilhoffer ( 193)

I've seen a few different approaches to this, but I use a generic utility method as such:

public static T DeepClone<T>(T obj)
{
 using (var ms = new MemoryStream())
 {
   var formatter = new BinaryFormatter();
   formatter.Serialize(ms, obj);
   ms.Position = 0;

   return (T) formatter.Deserialize(ms);
 }
}

Notes:

  • Your class MUST be marked as [Serializable] in order for this to work.
  • Your source file must include the following code:

    using System.Runtime.Serialization.Formatters.Binary;
    using System.IO;
    
function main()
{
   Hello();
}

function Hello()
{
  // How do you find out the caller function is 'main'?
}

Is there a way to find out the call stack at all?

Answered By: Greg Hewgill ( 198)
function Hello()
{
    alert("caller is " + arguments.callee.caller.toString());
}
140
Sam McAfee

Suppose you're developing a software product that has periodic releases. What are the best practices with regard to branching and merging? Slicing off periodic release branches to the public (or whomever your customer is) and then continuing development on the trunk, or considering the trunk the stable version, tagging it as a release periodically, and doing your experimental work in branches. What do folks think is the trunk considered "gold" or considered a "sand box"?

Answered By: Brian R. Bondy ( 114)

I have tried both methods with a large commercial application.

The answer to which method is better is highly dependent on your exact situation, but I will write what my overall experience has shown so far.

The better method overall (in my experience): The trunk should be always stable.

Here are some guidelines and benefits of this method:

  • Code each task (or related set of tasks) in its own branch, then you will have the flexibility of when you would like to merge these tasks and perform a release.
  • QA should be done on each branch before it is merged to the trunk.
  • By doing QA on each individual branch, you will know exactly what caused the bug easier.
  • This solution scales to any number of developers.
  • This method works since branching is an almost instant operation in SVN.
  • Tag each release that you perform.
  • You can develop features that you don't plan to release for a while and decide exactly when to merge them.
  • For all work you do, you can have the benefit of committing your code. If you work out of the trunk only, you will probably keep your code uncommitted a lot, and hence unprotected and without automatic history.

If you try to do the opposite and do all your development in the trunk you'll have the following issues:

  • Constant build problems for daily builds
  • Productivity loss when a a developer commits a problem for all other people on the project
  • Longer release cycles, because you need to finally get a stable version
  • Less stable releases

You simply will not have the flexibility that you need if you try to keep a branch stable and the trunk as the development sandbox. The reason is that you can't pick and chose from the trunk what you want to put in that stable release. It would already be all mixed in together in the trunk.

The one case in particular that I would say to do all development in the trunk, is when you are starting a new project. There may be other cases too depending on your situation.


By the way distributed version control systems provide much more flexibility and I highly recommend switching to either hg or git.