Practical or not: two machines, one developer, working against one codebase?

[Guest]

I'm a standalone developer with full access to my code and servers and
nobody else I need to cooperate with.I'm trying to think creatively about
ways to speed up my VS.NET development work. The process of builds in my
environment is slow, and I find myself giving my brain a rest too
frequently.

One way to speed compile times is to follow ScottGu's suggestions:
http://weblogs.asp.net/scottgu/arch...b-Project-Build-Performance-with-VS-2005.aspx

Another is to split my solution up into projects, per a message earlier this
week.

Another solution is to buy a faster machine. I'm looking for suggestions on
the fastest machine to buy for this purpose in 2007 as well as counsel on
whether, say, 4 gigs of RAM would make a significant difference.

I just had another idea: We have no shortage of reasonably capable machines.
If it were possible to work on two machines, switching back and forth while
one was in the process of build, that would speed things somewhat.

I'm wondering whether this is practical technically. Presumably it would
require keeping code in a third place -- say, on our servers. I don't know
if that's even possible.

Anyone have something like this set up? Thanks.

-KF

 

[marss]

I just had another idea: We have no shortage of reasonably capable machines.
If it were possible to work on two machines, switching back and forth while
one was in the process of build, that would speed things somewhat.

I'm wondering whether this is practical technically. Presumably it would
require keeping code in a third place -- say, on our servers. I don't know
if that's even possible.

Set some team development tool (Microsoft Visual SourceSafe, for
example) and work. If you are "multitasking" developer you can work
with two different files, otherwise - work with a single file and
periodically merge changes.
But I guess to split the solution into projects is the better idea.