updating directory after non-recursive checkout

[Jay Berkenbilt <ej...@ql.org>]

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:

  software/
     jobutil/
        101/
	102/
	103/
	...

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
file:///tmp/repo/software
; ls -AF
.svn/

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
file:///tmp/repo/software/jobutil

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 <ej...@ql.org>
http://www.ql.org/q/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: updating directory after non-recursive checkout

[Jay Berkenbilt <ej...@ql.org>]

I've thought of one possible solution to this problem:

>   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:
>
>     software/
>	jobutil/
>	   101/
>	   102/
>	   103/
>	   ...
>
>   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

Organize the repository as follows:

/skel
/trunk
/tags
/branches

Under /skel, create an empty directory structure that has the top
level directories of all the separate things people may want to work
on individually.  Check out from skel by default, rather than trunk.
Then use svn switch to switch individual subdirectories to trunk (or a
branch or tag) and do the real work there.

For example:

; alias svn-url="svn info | awk '"'/^URL:/ {print $NF}'"'"
; alias svn-trunk='svn-url| sed -e s,/skel/,/trunk/,'
; alias svn-skel='svn-url| sed -e s,/trunk/,/skel/,'


; svnadmin create /tmp/repo
; R=file:///tmp/repo
; svn co $R
Checked out revision 0.
; cd repo
; svn mkdir skel trunk branches tags
; cd skel
; svn mkdir software software/jobutil
; cd jobutil
; svn mkdir 101 102 103
; cd ../../..
; svn ci -mnew
; cd ..
; rm -rf repo

; svn copy -mnew $R/skel/software $R/trunk

Now all developers check out skel like this:

; svn co $R/skel/software

If I want to work on job 101:

; cd software/jobutil/101
; svn switch `svn-trunk`

Start working normally.

To add a new project:

; cd ..../software/jobutil
; svn-url
file:///tmp/repo/skel/software/jobutil
; svn mkdir -mnew `svn-url`/104
; svn copy -mnew `svn-url`/104 `svn-trunk`/104
; svn update
; cd 104
; svn switch `svn-trunk`

When I'm finished working and don't want 104 "checked out in my
sandbox" (to use CVS terminology), I can just cd to 104 and run

; svn switch `svn-skel`

Can anyone comment on this or think of something better?  With a few
scripts to help enforce policy (like having a script that does the add
in skel, copy to trunk, and switch in one operation), this could
actually work very well and would be smoother than CVS because you
wouldn't have to worry about whether to include -d or not depending on
where you were.

-- 
Jay Berkenbilt <ej...@ql.org>
http://www.ql.org/q/


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org