[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

When does svn co -N make sense?

From: <junkio_at_cox.net>
Date: 2003-06-03 02:26:58 CEST

Please bear with some background before my real question.

I have three projects a, b, and c under /trunk/ of my
repository, and I want to take only project a and c to my laptop
to work on road. I am not taking b because I do not intend to
work on it right now, but I want to be able to 'svn update' once
I am back and finished synching changes to a and/or c. Also
maybe I am short of disk space on my laptop.

I could do this:

  laptop$ svn co http://server/svn/trunk/ .
  laptop$ rm -fr b
  laptop$ ls
  ./ ../ .svn/ a/ c/
  laptop$ svn st
  ! b

and later I could run "svn update b" to get it back.

But this forces me to check out 'b', which could be huge, first.
Which I may want to avoid.

I could do:

  laptop$ svn co http://server/svn/trunk/a a
  laptop$ svn co http://server/svn/trunk/c c
  laptop$ ls
  ./ ../ a/ c/

But this does not let me say "svn st" to remind me that I have
"b" under the trunk which I am not taking with me.

Now the real question.

I thought I could do the following to achieve what I want
without first checking out everything under trunk/, but that
does not seem to be the case:

  laptop$ svn co -N http://server/svn/trunk/ .
  laptop$ svn co http://server/svn/trunk/a a
  laptop$ svn co http://server/svn/trunk/c c
  laptop$ ls
  ./ ../ .svn/ a/ c/
  laptop$ svn st
  ? a
  ? c

I am reading this output as "the directory (trunk) checked out
with -N does not know anything what is underneath".

Is there way to make this behave better (the definition of
better being "as if I checked out everything and then removed
subtree b")?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 3 02:27:47 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.