Re: branching question

Haggerty, Joshua wrote:
> We have a subversion repository (1.6) that has x (say 1000) files in
> trunk. When we release- we only need to *branch* 5 of those files for
> instance as we only develop and push those 5 files out. The branching
> works fine for files directly under trunk- but if I try to *branch* a
> file on a sub directory- I get a path not found. Examples below (using
> Tortoise 1.6 client).
>
> 1-*Branch* /trunk/a.sql to /branches/CR500/a.sql - works fine.
>
> 2-*Branch* /trunk/US_1/sql/ to /branches/CR500/US_1/sql - works but
> copies all files under sql into the *branch* which is undesired.
>
> 3-*Branch* /trunk/US_1/sql/a.sql to /branches/CR500/US_1/sql/a.sql -
> path not found (basically svn copy command will not create the subdir).
>
> The work arounds would be-
> a- set up the sub structure manually in every *branch* before branching,
> which is very undesired as we have very nested structures.
> b- instead of branching- set up just the files I need from trunk and add
> to the *branch*. The problem here is I lose all history as subversion
> sees it as a new file.
> c- use method 2 above, which presents some risks with our deployment
> process as well as other issues.
>
> For our front end projects- we *branch* the whole structure as we deploy
> the whole structure every time. So no issues. For this environment's
> projects, we have so many files, deploying in that manner is not
> beneficial.

Joshua,

this is the fundamental insight: deploying _in that manner_ might well
be the problem.

> I am rather new to subversion, but this doesn't seem like it would be an
> uncommon usecase, so I have a feeling I missing something fundamental
> here. Can anyone point me in the right direction?

In Subversion, you usually branch the whole tree, project, module,
system. Whatever your top-level unit is. Branching is "cheap" in that it
is copy-on-write. Unchanged items on the branch just refer back to the
revision they were copied from.

The Subversion Book explains this concept very well.

http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html

In your thousands-of-files scenario, only five items get changed on the
branch. In your other scenario, perhaps most of the items get changed.

Either way, all you have to do is ask Subversion for a list of changed
items on the branch. Use that as the input to your deployment mechanism.

You probably should consider scripting the deployment procedure. Doing
this using a GUI is prone to error.

Using the CLI, something like the following should work. (Using Bourne
Shell syntax, some common UNIX tools and http://svn.collab.net/repos/svn
/branches/1.6.x as an example. On Windows, try Cygwin.)

Assume you have a working copy of the branch and the current working
directory is at its root.

This tells you the revision you branched from.

$ svn log --quiet --incremental --stop-on-copy \
> | tail -1 | cut -d ' ' -f 1
r35888

Now you determine the changed paths on the branch.

This tells you what items got deleted. (Your scenario does not mention
deletes or renames for some reason?)

$ svn diff --summarize -r r35888:HEAD | grep ^D | cut -c 9-
TODO-1.6

This tells you what items got added or changed in some way.

$ svn diff --summarize -r r35888:HEAD | grep -v ^D | cut -c 9-
STATUS
build.conf
www/tools_contrib.zh.html
www/faq.zh.html
www/faq.ja.html
www/tools_contrib.html
win-tests.py
subversion/libsvn_ra/compat.c
subversion/libsvn_diff/diff_file.c
...

-- 
Michael Diers, Senior Consultant/Technical Director
elego Software Solutions GmbH, http://www.elego.de
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2375457
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].