On Mon, Dec 02, 2002 at 07:03:36PM +0100, Fabio Fracassi wrote:
What I like to do is porting one local change at a time e.g. I
have the following tags
VendorRelease
basicChanges
extension1
extension2
product
I'd like to take the new Vendor version and first apply the basicChanges,
On Fri, Nov 22, 2002 at 11:35:17AM -0500, MacMunn, Robert wrote:
When I merged 2 files I got extra lines teling me where the merged lines
where.
Is there any way around this ?
The extra lines with and appear only when there are
conflicts in the merged files. They are a feature, not a bug,
I see that when I import a new vendor version (to the vendor branch),
files that have been removed by the vendor (but not modified by me)
are not removed. Is this a bug or a feature?
Any sugestion for an easy way to find and remove these files?
Thanks
/npat
--
In the beginning the Universe was
On Thu, Oct 31, 2002 at 12:43:18PM -0800, Kaz Kylheku wrote:
On Thu, 31 Oct 2002, Nick Patavalis wrote:
Did you complete the merge merge from the vendor branch by
doing the update/checkout -j old -j new ?
Oooops! You're right!
/npat
--
He who joyfully marches to music in rank and file
On Thu, Oct 31, 2002 at 04:30:11PM -0500, Larry Jones wrote:
(note that you *MUST* use the actual release tags for this to work as
opposed to using branch:yesterday or any similar schemes)
Why
--
Developing skills that depend on a proprietary product makes you a
sharecropper on your own
Reading from the CVS (info) manual [keyword substitution / using
keywords]:
To include a keyword string you simply include the relevant text
string, such as `$Id$', inside the file, and commit the file. CVS
will automatically expand the string *as part of the commit
operation*.
Is this
On Thu, Oct 24, 2002 at 04:49:08PM -0400, David R. Chase wrote:
Hello there,
I'm mainly trying to obtain
finer granularity access control via pserver (or other remote access)
authentication rather than via the filesystem's uid/gid and related
permissions.
What's wrong with uid/gid based
On Fri, Oct 25, 2002 at 02:07:22PM -0400, Eric Siegerman wrote:
Stow (http://www.gnu.org/software/stow/stow.html) is excellent
for this! It's basically a package manager, but an extremely
lightweight one.
I agree. Stow rules! It is a fine example of treating problems with a
purelly unix
On Fri, Oct 25, 2002 at 01:03:40PM -0500, Steve Buehler wrote:
Does anybody know
of a few that I can checkout?
Try http://freshmeat.net; and search for CVS. I am sure you will find
some. I hava not used any, but I am certain I've seen a few when I was
looking arround.
/npat
--
This
On Thu, Oct 24, 2002 at 08:15:30AM -0400, James Hughes wrote:
Nick Patavalis wrote:
What tags exist, listed in chronological order?
What are the names of the tags corresponding to vendor-branch
imports, in chronological order?
What tags exist in a specific branch?
cvs
On Thu, Oct 24, 2002 at 09:10:30AM -0500, Todd Denniston wrote:
Nick Patavalis wrote:
Take for instance this very real example (my source-tree is a
linux-kernel):
cvs status -v Makefile
===
File: Makefile
On Thu, Oct 24, 2002 at 09:24:41AM -0700, Johnson, Susan wrote:
Nick, I would need a tool like that too. People have
pointed me to winCVS (windows tools) but I really
want a command-line-based output.
Looking arround I found a very interesting little perl program. I's
called cvs-exp, its
On Tue, Oct 22, 2002 at 08:28:43PM -0400, Greg A. Woods wrote:
In effect, that after the import a user checking out from the branch
might get files from the newer vendor version?
No, that's one thing that shouldn't happen. Indeed that's part of the
problem though -- after an import and
Is there any way to get, via a script of something, information about
the tags in a CVS-controlled tree? I want for example to answer the
questions like the following:
What tags exist, listed in chronological order?
What are the names of the tags corresponding to vendor-branch
imports, in
On Wed, Oct 23, 2002 at 01:49:36PM -0500, Todd Denniston wrote:
Nick Patavalis wrote:
You merge the local changes
cvs co -j VENDOR_R1 -j VENDOR_R2 module
You resolve the confilicts, test the new sources, and generaly make
sure that everything is stable. Then commit your changes
On Wed, Oct 23, 2002 at 01:58:27PM -0700, Shankar Unni wrote:
I would think that with the situation above, doing a cvs tag
VENDOR_R2_MERGED in the working directory where conflict resolution
was finished would be the safest method, to be sure you tagged the
resolved files and not
On Wed, Oct 23, 2002 at 02:24:47PM -0700, Shankar Unni wrote:
The problem was, if one of the files was *deleted* on the branch, cvs
tag wouldn't move the tag for that file - you'd have to use cvs rtag for
it. The developer in question had done separate cvs rms on the
mainline and the branch,
We have a cvs tree, on which we work for quite some time now since the
sources were first imported. As a result a considerable amount of
changes have been collected. Now the vendor has shiped a new version
and we would like to merge the changes back to our tree. Due to the
complexity of the task
On Tue, Oct 22, 2002 at 06:16:31PM -0400, Greg A. Woods wrote:
It's not really safe to use normal branches in a vendor-branched
module, at least not one in which you plan to do more cvs imports to
the vendor branch.
What do you mean!?! That if I create a branch (a normal branch), and
latter
19 matches
Mail list logo
