[cvsnt] Re: When is the best time(s) to merge changes into themaintrunk?

James Neave JNeave at spursolutions.com
Wed Apr 27 10:35:12 BST 2005


Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.


Aha!

So *THAT'S* what mergepoints do.
I read about them on CVSNT.org and didn't really get the explanation.

Why couldn't they have just said what you just said!?

So if I was using CVS Classic, lots of small merges would be insane?

And I *really* mustn't use SmartCVS to do the merging, that doesn't
support mergepoints at all.

OK, thanks!

J.

-----Original Message-----
From: Bo Berglund [mailto:Bo.Berglund at system3r.se] 
Sent: 27 April 2005 10:30
To: James Neave; Bo Berglund; cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook
Subject: RE: [cvsnt] Re: When is the best time(s) to merge changes into
themaintrunk?

The reason we do the small merges is that CVSNT is so good at handling
mergepoints. We never have to tag anything around the merge, just update
with merge, fix conflicts and commit so the mergepoint gets stored in
the repository. From then on CVSNT knows from where the two branches are
already in sync so only the changes from that point will be calculated
the next time. :-)

/Bo

-----Original Message-----
From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org]On Behalf
Of James Neave
Sent: den 27 april 2005 10:36
To: Bo Berglund; cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook
Subject: RE: [cvsnt] Re: When is the best time(s) to merge changes into
themaintrunk?


Hi,

Ah, that's kinda backwards from what we do.
We use TRUNK for future development. Every so often we freeze
development and test TRUNK until we are happy it is stable. We then call
that a release and tag and branch it.

Any bugs then found in that release or urgent features required are done
on the branch, not on the TRUNK.

I've only ever done one merge with CVS, merging the branch v1_1_patches
back into TRUNK when we were releasing v1_2.

But that seemed awkward because when I finished the merge I had to test.
During this testing there is always the possibility that more changes
would be made to v1_1_patches, meaning more merging and more testing and
more time.

This mimics how we did (still do) things in VSS.

But even though you do things backwards from us, I get the feeling that
your small branches that get merged often work well, yes?

I think I'll try lots of small merges rather than One Big Merge and see
if that makes big releases easier.

Thanks,

James. 

-----Original Message-----
From: Bo Berglund [mailto:bo.berglund at telia.com] 
Sent: 27 April 2005 06:39
To: cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook
Subject: [cvsnt] Re: When is the best time(s) to merge changes into the
maintrunk?

On Wed, 27 Apr 2005 06:57:57 +0200, Bo Berglund
<bo.berglund at telia.com> wrote:

>On Tue, 26 Apr 2005 16:24:59 +0100, "James Neave"
><JNeave at spursolutions.com> wrote:
>
>>I'm thinking about doing it every time I make a change to the patches
>>branch, that way I won't have lots to do when a new release is due.
>
>If you do this you might as well just work on TRUNK, you are
>effectively not using the branch the way you describe it...
>

Adding to the comment above...

What we do is this:
We assign a branch to the sources whenever there is new feature stuff
that needs developing over some time. During that time things may also
happen on TRUNK (normal bugfixes and small enhancements).

So in order to keep the merging job small and to have all new stuff on
the branch we continuously merge in from HEAD to the branch to get the
latest state of TRUNK into the branch. We can then solve any conflicts
on the branch.
Later when the feature is ready to be introduced we just merge down
the branch to HEAD and this is typically trivial since the branch
already contains the HEAD code.

Our builds are done from HEAD, but the result (the binary exe or dll
file) is not committed to the bin folder until tested and approved. We
keep the bin folder on a branch for the rare cases when we want to
version intermediate binary states.
The installer gets built from exports out of the bin folder using
HEAD.

/Bo
_______________________________________________
cvsnt mailing list
cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs

The information in this email is confidential and may be legally
privileged.  It is intended solely for the addressee.  Access to this
email by anyone else is unauthorised.

If you are not the intended recipient, any disclosure, copying,
distribution or any action taken or omitted to be taken in reliance on
it is prohibited and may be unlawful.

The contents of an attachment to this email may contain software viruses
that could damage your own computer systems.  Whilst The Spur Group of
Companies has taken every precaution to minimise the risk, we cannot
accept liability for any damage that you sustain as a result of software
viruses.

_______________________________________________
cvsnt mailing list
cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs



More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook