Re: Easiest way to move a branch to the trunk

2001-02-02 Thread Stephen Rasku

Brian Murrel wrote:

>I have a project/repository which has a main branch (trunk) for
>stable, released versions and a development branch.  The development
>branch was branched off of the main branch a while ago for 
development
>and has going along gangbusters.  Now it is time to release.  What is
>the easiest way to move the develoment branch onto the main branch so
>that what is on the main branch is completely replaced by the
>development branch.
>
>I realize of course I could use "cvs update -j" to move it all over
>but that is going to create a boatload of conflicts.  I can deal with
>conflicts easily (and tediously) enough but I wonder why I should 
need
>to bother.  It seems that I should be able to simply replace the
>contents of the main branch with the development branch in an easier
>way, no?
>
>All suggestions welcome, thanx.

I know that this is shutting the barn door after the horses have gone 
but your new development should have been on the trunk and you should 
have had stable branch.  Since the new development is already on the 
head this removes the need to merge (or put) new development there.

However, to solve your current problem you will have to write a 
script.  Assuming that you have a workspace already checked out on the 
head, this is how you put the branch version of a file to the head:

cvs update -p -r branch-tag foo.c > foo.c

You will have to iterate this over every file in the tree.  Once all 
the files are updated you can check in the whole repository.

-- 
Stephen Rasku   E-mail: [EMAIL PROTECTED]
Senior Software EngineerWeb:http://www.pop-star.net/
TGI Technologies


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: Easiest way to move a branch to the trunk

2001-02-02 Thread Brian J. Murrell

On Fri, Feb 02, 2001 at 08:56:26AM -0800, Stephen Rasku wrote:
> Brian Murrel wrote:
> 
> I know that this is shutting the barn door after the horses have gone 
> but your new development should have been on the trunk and you should 
> have had stable branch.

Of course.  It was a little more abstract that I previously eluded but
your points are right on.  Both the trunk and the branch were parallel
development, one only cutting edge, the other bleeding edge.  I should
have forseen moving the bleeding edge to the cutting edge though and
did it as you said.

> Since the new development is already on the 
> head this removes the need to merge (or put) new development there.

Right.

> However, to solve your current problem you will have to write a 
> script.  Assuming that you have a workspace already checked out on the 
> head, this is how you put the branch version of a file to the head:
> 
>   cvs update -p -r branch-tag foo.c > foo.c

Looks good.

> You will have to iterate this over every file in the tree.  Once all 
> the files are updated you can check in the whole repository.

But what to do about files that are on the head but not in the branch
and vice versa?  Figure out which ones are which and do some "cvs new"
and "cvs delete"s?

Once I have done that I will correct the function of the branches.

Thanx,
b.

-- 
Brian J. Murrell

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: Easiest way to move a branch to the trunk

2001-02-02 Thread Stephen Rasku

Brian Murrel wrote:

>But what to do about files that are on the head but not in the branch
>and vice versa?  Figure out which ones are which and do some "cvs 
new"
>and "cvs delete"s?
>

If you cvs update -p a file that only exists on the branch it will 
create it.  If you do:

cvs status new-file

it will show:

cvs server: use `cvs add' to create an entry for local.h

If you cvs update -p a file that doesn't exist on the branch, you will 
get a zero length file.

These should be good clues as to which files to add and delete.

By the way, what's with the weird e-mail addresses (e.g. 
[EMAIL PROTECTED])?

-- 
Stephen Rasku   E-mail: [EMAIL PROTECTED]
Senior Software EngineerWeb:http://www.pop-star.net/
TGI Technologies


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: Easiest way to move a branch to the trunk

2001-02-02 Thread Brian J. Murrell

On Fri, Feb 02, 2001 at 11:37:29AM -0800, Stephen Rasku wrote:
> Brian Murrel wrote:
> 
> If you cvs update -p a file that only exists on the branch it will 
> create it.  If you do:
> 
>   cvs status new-file
>   
> it will show:
> 
>   cvs server: use `cvs add' to create an entry for local.h
>   
> If you cvs update -p a file that doesn't exist on the branch, you will 
> get a zero length file.
> 
> These should be good clues as to which files to add and delete.

So what I was thinking is true.  Thanx.

> By the way, what's with the weird e-mail addresses (e.g. 
> [EMAIL PROTECTED])?

It's a "onetime" address.  When I mail to unknown destinations (which
includes lists -- which allow anonymous posting anyway) a unique return
address is created for that message and it is logged.  If the address
starts attracting spam at some point, a) I know where the leak is b) I
can turn it down (assuming it's outlived it's usefulness) to prevent
the spam from successfully even being delivered to may mail server or
c) I can add it to my spam-traps for early detection and resistance of
spam sources.

b.

-- 
Brian J. Murrell

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: Easiest way to move a branch to the trunk

2001-02-02 Thread Eric Siegerman

On Fri, Feb 02, 2001 at 05:07:31AM -0800, Brian J. Murrell wrote:
> I have a project/repository which has a main branch (trunk) for
> stable, released versions and a development branch.  The development
> branch was branched off of the main branch a while ago for development
> and has going along gangbusters.  Now it is time to release.  What is
> the easiest way to move the develoment branch onto the main branch so
> that what is on the main branch is completely replaced by the
> development branch.
> 
> I realize of course I could use "cvs update -j" to move it all over
> but that is going to create a boatload of conflicts.  I can deal with
> conflicts easily (and tediously) enough but I wonder why I should need
> to bother.  It seems that I should be able to simply replace the
> contents of the main branch with the development branch in an easier
> way, no?
> 
> All suggestions welcome, thanx.

Here are some instructions I recently posted for someone else,
lightly edited to reflect your situation, which is somewhat
different from theirs:

  - Create a directory containing the latest development source,
WITHOUT any CVS subdirectories (use "cvs export", or manually
delete the CVS subdirectories from a preexisting sandbox).
I'll call this .

  - Create another sandbox on the trunk (ie. the stable version),
eg. using "cvs co" with no -r or -D options, or "cvs update -A".
This sandbox is hereafter referred to as .

  - Get a list of the stable files you've deleted in development:
  % cd ; find . -print | sort >/tmp/stable
  % cd ; find . -print | sort >/tmp/dev
  % comm -23 stable dev >/tmp/deleted-files

  - Recursively copy  (new files, modified files, unmodified
files -- the whole works) OVER TOP OF your  sandbox;
this will result in  containing your development
source, but with its CVS admin info pertaining to the stable
version (not quite -- any files you've deleted in development
will still be present; we'll deal with this momentarily)

  - Now, "cd ; cvs -nq update" will give you a complete
list of the files you've added (flagged by "?") and changed
(flagged by "M") -- but NOT the ones you've deleted, which is
why you had to make a list of those before overlaying the
two directories

  - "cvs add" any of the "?"-flagged files that should be
CVS-tracked (exclude any cruft that's made it into 
-- temporary files that people forgot to delete, etc.) 

  - "cvs remove -f" the files you've deleted in development, ie.
the ones in the list you made above (though of course you'll
want to verify that none of them were deleted by accident in
the distant past :-)

  - "cvs commit"

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
Interviewer: You've been looking at the stars all your life:
Is there anything in astrology?
Arthur C. Clarke: It's utter nonsense.  But I'm a Sagittarius,
so I'm naturally skeptical.

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: Easiest way to move a branch to the trunk

2001-02-02 Thread Richard Cobbe

Lo, on Friday, February 2, Brian J. Murrell did write:

> I have a project/repository which has a main branch (trunk) for
> stable, released versions and a development branch.  The development
> branch was branched off of the main branch a while ago for development
> and has going along gangbusters.  Now it is time to release.  What is
> the easiest way to move the develoment branch onto the main branch so
> that what is on the main branch is completely replaced by the
> development branch.

We're about to have to do this at work ourselves, because the folks who
created the branch didn't really understand what they were doing, and so
got the trunk & branch backwards.  (New development has been on the
branch---evil!)

If you tagged the trunk at the point where you branched, then this should
actually be pretty easy.  Call the tag PRE-BRANCH-TAG:

* Get a working copy on the trunk; make sure there are no uncommitted
  changes.

* If you want to preserve that line of development, you may want to tag and
  branch here.

* Back on the trunk, roll back all changes made since the branch:
cvs update -j HEAD -j PRE-BRANCH-TAG

* Resolve any conflicts, although I'd suspect that there wouldn't be any.
  You may also want to commit here, but that's up to you.

* cvs update -j PRE-BRANCH-TAG -j DEVELOPMENT-BRANCH
to incorporate all changes made on the development branch.  Again,
there shouldn't be any conflicts.

* commit.

If you *don't* have PRE-BRANCH-TAG, then you're up a creek, and you'll have
to go with one of the other more labor-intensive suggestions posted.

Richard

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs