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

Re: branching: dragging along other branch

From: Thom Borton <borton_at_phys.ethz.ch>
Date: 2004-07-06 19:49:08 CEST

It seems that I have found the solution :-) The solution lies in svn switch.

 From the svn handbook:

In other words, if a user knows that the branch-work only needs to
happen on a specific subdirectory, they use svn switch to move only that
subdirectory to the branch. (Or sometimes users will switch just a
single working file to the branch!) That way, they can continue to
receive normal 'trunk' updates to most of their working copy, but the
switched portions will remain immune (unless someone commits a change to
their branch). This feature adds a whole new dimension to the concept of
a “mixed working copy”—not only can working copies contain a mixture of
working revisions, but a mixture of repository locations as well.

Thom

Thom Borton wrote:

> I have several files in the trunc of a project/repository, let's call
> them A, B and C.
>
> Now I want to create a branch of the project, in which I will make
> changes to file C, call the new one C'.
>
> Meanwhile, the development of files A and B in the trunc will go on,
> call them A_ and B_. I know that the development of these files does not
> interfere with file C.
>
> When I do a checkout of the branch, I will get the files A, B (from when
> the branch was initiated) and C' which is the last change to C of the
> branch that I commited.
>
> BUT: What I want is to checkout the new A_ and B_ and the new C', i.e.
> "the newest of trunc and branch".

-- 
Thom Borton
Switzerland
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jul 6 21:20:49 2004

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

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