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

updating directory after non-recursive checkout

From: Jay Berkenbilt <ejb_at_ql.org>
Date: 2004-03-25 20:08:35 CET

I've been running CVS for 8 years and just started playing with
Subversion yesterday. I'm trying to make sure I can do everything
with subversion that I currently do with CVS. So far, I've run into
one problem: updating a single directory after doing a non-recursive
checkout of its parent. This is best explained with an example.

One of my CVS repositories holds several dozen small "job-specific"
programs that support production work on a specific job for a specific
client. Our repository looks like this:


where each numbered directory is for one job. Most developers are
only working on a few jobs at a time, and most of the software is
stable and doesn't require much modification. Our procedure in CVS is
to do a non-recursive checkout of software/jobutil and then to get a
directory that we need with cvs update. For example:

cvs co -l software # -l is "local", i.e., non-recursive
cd software
cvs update -ld jobutil
cd jobutil
cvs update -dP 103

We have several modules defined in CVS defined with the -a flag to
preserve directory structure. If a module for 103 had been defined
like this:

103 -a software/jobutil/103

someone could go to the top level (parent directory of "software" in
their sandbox) and type cvs co -P 103 to get the same result as above.
This works perfectly no matter what is or isn't checked out. At all
times, a person's sandbox may contain an arbitrary subset of the
overall repository, and cvs still treats the whole thing as one unit.
In other words, cvs update from the top level will update everything
that is checked out. cvs update -d from the top level will update
everything that is checked out and check out everything that isn't.

Preserving relative directory structure is important for us since it
happens in some cases that one job's utilities may depend on another.
For example, job 108 may be a special case of job 103 where an
additional step is performed, and job 108's test suite may access
files from job 103's test suite. We always want job 103 to be able to
look in ../108 and know that this is going to work.

I am, so far, unable to figure out how to get this to work in
subversion. Consider the following sequence of steps. I'm using "; "
as a prompt below so that you can conveniently cut and paste all lines
starting with "; " from the email into a shell running bash (or zsh).

# Here is a useful alias:
; alias svn-url="svn info | awk '"'/^URL:/ {print $NF}'"'"

; svnadmin create /tmp/repo
; R=file:///tmp/repo
; svn mkdir -mnew $R/software $R/software/jobutil
Committed revision 1.

# Go to an empty directory

; mkdir 1
; cd 1

; svn co -N $R/software
Checked out revision 1.
; cd software
; svn-url
; ls -AF

At this point, I can figure out no way of getting the jobutil
directory there in a manner similar to what cvs update -d jobutil
would do.

; svn update
At revision 1.
; svn update jobutil
svn: 'jobutil' is not under version control
; svn co `svn-url`/jobutil
svn: Working copy 'jobutil' not locked

Hmm. What does that mean? (other than I'm probably doing something I
shouldn't be)

; svn status
? jobutil

; cd jobutil
; svn-url

Okay, we're good inside jobutil, but we are not in the same state that
we would have been if jobutil had appeared when we checked out the
top-level software directory. The jobutil working copy is, in some
sense, independent from its parent even though it resides in the
correct location relative to its parent.

Now if I go into a different directory and check out the whole thing:

; cd ../../..
; mkdir 2
; cd 2
; svn co $R/software
Checked out revision 1.
; cd software
; svn status
[no output]
; ls -AF
.svn/ jobutil/

Clearly what I'm doing in the "1" directory is wrong. What should I
be doing to get this functionality? Does this work? Do I have change
my paradigm here?

I've done quite a bit of additional experimentation, but this message
is already too long. I can provide more detail if desired. Hopefully
I've communicated the problem.

I'd be grateful for any assistance.

Jay Berkenbilt <ejb@ql.org>
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 25 20:09:16 2004

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