¢¹ ¿øÄ¡¾ÊÀº Á¤º¸¿´´Ù¸é Á¤ÁßÈ÷ »ç°ú µå¸®¸ç, ¼ö½Å °ÅºÎ¸¦ ÇØÁÖ½Ã¸é ´ÙÀ½ºÎÅÍ´Â ¸ÞÀÏÀÌ ¹ß¼ÛµÇÁö ¾ÊÀ» °ÍÀÔ´Ï´Ù.¢¹ ¸ÞÀÏŬ¶óÀ̾ðÆ®ÀÇ ÇÊÅÍ ±â´ÉÀ» ÀÌ¿ëÇÏ¿© [±¤°í] ¹®±¸¸¦ ÇÊÅ͸µÇÏ¸é ¸ðµç ±¤°í ¸ÞÀÏÀ» ÀÚµ¿À¸·Î Â÷´ÜÇÏ½Ç ¼ö ÀÖ½À´Ï´Ù.
¼ö½Å°ÅºÎ
___
Info-c
Oops, my previous post referred to a script that collects a bill of
material, which was omitted. Here's one that I quickly threw together,
updated for CVS v1.10 and later. Its command line lists directories in
which bills of materials are gathered, with recursive descent. If no
command line ar
>--- Forwarded mail from [EMAIL PROTECTED]
>Thanks for the reply. I performed the search you mentioned and found the
>following message
> http://ccvs.cvshome.org/servlets/ReadMsg?msgId=5846&listName=info ).
>However, that message also sugessts searching on "submit/assemble" which
>seems to imp
If someone is making huge, disruptive changes to the project, then it
certainly is best to spawn a branch and bite the bullet with a nasty merge.
Or, better yet, spawn a branch for continuing work and put the disruptive
change on HEAD; that way you can control the depth of your branches if
there a
Thanks for the reply. I performed the search you mentioned and found the
following message
http://ccvs.cvshome.org/servlets/ReadMsg?msgId=5846&listName=info ).
However, that message also sugessts searching on "submit/assemble" which
seems to imply I did not find the one you intended.
Anyway,
[ On Saturday, February 2, 2002 at 09:14:40 (+0100), C. Wienberg wrote: ]
> Subject: Re: using head revision in branch after add on branch
>
> You can only check them in into _one_ module.
Of course -- that's about the only way you'll ever make any kind of
change management system make sense!
>
I've found that is you plan to make a 'disturbing' change, it's best to
do that in a branch - get it working and merge it in. The idea is that
the HEAD branch *must* always build (at least after a short period
(hours max) of instability). So multiple dev branches for big
collaborative chang
Hi Greg,
> It all depends on where you make the changes, now doesn't it. If you
> make them in the working directory then you can just check them in.
> ...you wouldn't need to use 'cvs export'...
You can only check them in into _one_ module.
If we have one module for common stuff and one with s
