[nycbug-talk] OT: SVN problem

[James E Keenan]

On Oct 7, 2009, at 12:00 PM, talk-request at lists.nycbug.org wrote:

> Date: Tue, 6 Oct 2009 18:30:33 -0400 (EDT)
> From: Matt Juszczak <matt at atopia.net>
> Subject: [nycbug-talk] OT: SVN problem
>
> I'm having a really hard time figuring out an SVN problem that  
> should be
> so simple.  I've been pulling my hair out and thought maybe someone  
> on the
> list would know.
>
> oak$ svn copy trunk branches/stable
> A         branches/stable
> oak$ svn copy trunk branches/live
> A         branches/live
> oak$ svn ci -m "recreated stable and live branch"
> Adding         branches/live
> Sending        branches/live/htdocs/static/js/global.js
> Adding         branches/stable
> Sending        branches/stable/htdocs/static/js/global.js
> Transmitting file data ..
> Committed revision 120.
>
>
> Why is this thing singling out global.js?  These directories are  
> brand new
> - it's doing it even if I do branches/hahahatesting123.
>

I cannot definitely tell you what's going wrong.  However, I can say  
that if you are trying to create a new branch in your repository, you  
are not proceeding in the best manner.  The way I use -- and very  
reliably so -- is "URL to URL":

   svn cp file:///path/to/repository/module/trunk \
              file:///path/to/repository/module/branches/live -m  
"Creating 'live' branch of 'module' repository"

If you are copying over the Net, substitute 'http://' for 'file:///'  
above.

'svn cp --help' is your friend.  I read there (version 1.6.3):

"  SRC and DST can each be either a working copy (WC) path or URL:
     WC  -> WC:   copy and schedule for addition (with history)
     WC  -> URL:  immediately commit a copy of WC to URL
     URL -> WC:   check out URL into WC, schedule for addition
     URL -> URL:  complete server-side copy;  used to branch and tag
   All the SRCs must be of the same type.

"WARNING: For compatibility with previous versions of Subversion,
copies performed using two working copy paths (WC -> WC) will not
contact the repository.  As such, they may not, by default, be able
to propagate merge tracking information from the source of the copy
to the destination."

Jim Keenan