RE: [boost] Re: Problem on the CVS version of the top web page

[Michael van der Westhuizen]

We do a regular merge of branch changes into HEAD in our
source at work.

So far I've had a sum-total of 1 conflict...

Things to remember when merging:
  * where possible ignore whitespace
  * suppress keyword expansion
  * keep your sync tags well documented

I based our process at work on the following document:
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/Attic/README.SMP?re
v=1.1.2.9content-type=text/plainonly_with_tag=SMP

(you're probably going to have to paste that back together)

We used to have a huge problem with bringing changes
from one version into another (missing code etc.), but
the semi-automated merge process is much more reliable.

One word of warning: committers should think carefully
about what they put in commit messages. The person doing
the merge can resolve conflicts more easily if the
changes (and their intent) is well documented.

/Michael


-Original Message-
From: Janusz Piwowarski [mailto:[EMAIL PROTECTED]
Sent: 24 August 2003 06:50
To: Boost mailing list
Subject: Re: [boost] Re: Problem on the CVS version of the top web page


On Sunday, August 24, 2003, 7:15:11 AM, Daryle Walker wrote:

 I have a CVS Quick Reference Card lying around, and the entries for 
 checkout and update have a sub-option -j REV that says Merge in 
 changes.  That can't fuse one branch into another?  (I wouldn't want 
 to potentially hose our CVS experimenting with this.  Any experts out 
 there that know what this sub-option does?)

You're right, -j option with update command can merge changes between
branches. It works ok, marks places changed in both branches with
standard cvs markers  and .

Regards,

Janusz

___
Unsubscribe  other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost


**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

**

___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] boost::filesystem file restrictions

[Michael van der Westhuizen]

-Original Message-
From: Beman Dawes [mailto:[EMAIL PROTECTED]
Sent: 14 August 2003 04:56
To: Boost mailing list; [EMAIL PROTECTED]
Subject: Re: [boost] boost::filesystem file restrictions


At 06:03 AM 8/14/2003, Walter Landry wrote:

 I've started using boost::filesystem recently, and I'm mostly very
 happy.

 Wow! A very happy user. Or at least mostly very happy. That's good news:-)

 Seriously, it is a powerful motivator to get that kind of feedback.

Well, here's another happy user :-)

-- snip --

 I'm curious to hear what others would think of the above scheme.

Oddly enough I had a similar thought halfway through reading your 
mail - by the time I got to your proposal all I could think was yes.

As for the stack/heap question... I don't believe there is a way to
portably and reliably tell how memory was allocated (please correct me
if I'm wrong - code would be most welcome!).

Michael
___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost