Subversion Lock is based on both working copy and user

2 05 2009

Scenario: User ‘sankalp’ locks a file in his working copy and tries to commit some changes to the locked file from another working copy that was checked out under same username.

Result: Commit would fail, because the later working copy doesn’t get the file lock, only the first one does.

I stumbled upon this while locking a file via URL path, using FinalBuilder Subversion file lock (Actually ‘Subversion Generic‘ action). Although the lock is successful and can be seen from repository browser client, the working copy didn’t reflect it. So I had to lock the file based on its working copy path, and not based on its URL path. This made me realize that locks are specific to working copies, apart from being exclusive to users.

Also, if somehow you delete the working copy that had locked a file and cannot restore it back, the only way out seems to be breaking a lock on that particular file. Or is there any other way out?

Sources:

1. http://groups.google.com/group/tortoisesvn/browse_thread/thread/dbf3269ae304761d
2. http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-locking.html

Advertisements




Combining paths in .Net

5 04 2009

Whenever you are combining paths using Path.Combine(path1, path2), watch out for a subtle but deadly pitfall.

path1 should not have a front slash at the end and path2 should not have a front slash in the beginning. Things get really bad otherwise. I have realized this after wasting 5-6 hours of precious weekend sleep. I can’t help cussing myself, because I have a feeling that I had made this mistake before. @#$@#!$@#$%@#!@#@!$. 🙂

i.e.
string path1 = "c:\\tempdir";
string path2 = "subdir\\";
path3=Path.Combine(path1, path2)
/*path3 = c:\\tempdir\\subdir\\*/

But,

string path1 = "c:\\tempdir";
string path2 = "\\subdir\\";
path3=Path.Combine(path1, path2)
/*path3 = \\subdir\\*/

In my defense, I strongly feel that the library function should have taken care of this subtle variation. (Blame .Net 🙂 )

Anyways, find more information about this function here.





Different version formats for .Net & win32 components

9 03 2009

For a win32 dll or exe , the  fileversion attribute means following:

majorversion.minorversion.releaseversion.buildversion

Whereas, a .Net component has different interpretation of these numbers.  i.e.

majorversion.minorversion.buildnumber.revision

This means, if you have an  exe or dll with fileversion 1.0.0.2 from a vc++ project, then corresponding assemblyversion for a .Net exe or dll for same build would be: 1.0.2.0.

This was causing little confusion while I was working with FinalBuilder to version all project executables before applying MSBuild.  Right now, I have kept consistent version format for all project types  and am interpreting them as win32 style version information.

Any opinions?





A revelation: C# doesn’t allow default parameters

11 01 2009

Wondering why?

Check out: http://blogs.msdn.com/csharpfaq/archive/2004/03/07/85556.aspx.

Quoting their reasons below:

1. The first one is that the correlation between the code that the user writes and the code the compiler generates is less obvious. We generally try to limit magic when possible, as it makes it harder for programmers.

2. The second issue has to do with things like XML doc comments and intellisense. The compiler would have to have special rules for how it generates doc comments for the overloaded methods, and intellisense would need to have smarts to collapse the overloaded methods into a single method.

The first reason kind of makes sense. Allowing default parameters is like forcing the programmer to know about default parameters before using them. Although, default parameters can make your program look magical(!) (initializing something without doing anything), it makes it harder to read.

It sucks if you are used to default parameters.

Check out this link for more How To’s or FAQs in C#.

Sources:

1. http://blogs.msdn.com/csharpfaq/archive/2004/03/07/85556.aspx

2. http://blogs.msdn.com/csharpfaq/default.aspx





Addition to SunSPOT Emulator – Solarium

8 10 2008

I am very impressed by solarium – SunSPOT emulator tool available with SunSPOT SDK V4.0.
Using this tool you can run almost all your programs on virtual SPOTs. It is real boon if you don’t have sufficient number of sensor nodes.

However it currently lacks all radio monitoring, configuration functionalities. It would be wonderful, if we can emulate various environment conditions & add distance dimension to Solarium. This way, we could monitor & configure networks of virtual SPOTs, conduct radio based experiments on Solarium.

To further that, different sensing environments like day or night time, dry or humid weather, hot or cold weather etc.

What I am saying is, add to this emulator a simulator that would make virtual SPOT quite ‘real’.





Makes developer feel good :)

7 10 2008





Byte Array to String and vice versa – Java

17 09 2008

This is little stupid, but I wasted some time on this. The problem is

String s = "abc123";
byte[] b = s.getBytes();
System.out.println(b.toString());

Output: [B@3e25a5

You don’t get back the original string when you use toString().

If you want to get back the original string, you will have to use string constructor:

String s = "abc123";
byte[] b = s.getBytes();
System.out.println(new String(b));

Output: abc123.