[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: help with rlog

From: Jim Hyslop
Subject: Re: help with rlog
Date: Wed, 01 Mar 2006 10:56:06 -0500
User-agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

Hash: SHA1

sreekanth wrote:
> Hi,
>     I have a tree that's imported .Let 's say i have a file "file1" with 
> initial version (yes, that's the revision i have for all the files 
> that are imported), Now create a tag RLS_TAG1 on it. Then commit the next 
> version of it, now the revision number is 1.2(strange for me, but still).

That is expected behaviour, and is what is causing your problem.
'import' is designed to track third-party source code. When you import
code, it is automatically placed on a vendor branch. CVS assumes that
you do not want your changes to be mixed in with vendor-supplied
updates, so when you modify and check in the code locally, CVS
automatically puts those changes on the trunk. The next vendor-supplied
update would be applied with another 'import' command, where you would
provide the same vendor-branch as the initial import. Then you can
easily merge your changes into the vendor's changes.

> Now i do a tag RLS_TAG2. Now if i do a rlog of messages between RLS_TAG1 and 
> RLS_TAG2 using command
> cvs rlog -rRLS_TAG1::RLS_TAG2 <path>file1,
>  I was expecting the log message of the commit message that i just did(of 
> revision 1.2) , but instead i see the original commit message that was used 
> to Import this file into the tree(revision, Is that an expected 
> behaviour? It's essentially breaking my script to retrieve the logs between 
> two subsequent Tags. 
This is expected behaviour. -r expects the two tags to be on the same
branch. In this case, they aren't.

> Is there a work around to fix this issue?

The command 'cvs admin -b' will move all files to the trunk. Then, move
the RLS_TAG1 from the branch to the trunk. Actually, to be safe, I'd
leave RLS_TAG1 where it is, and apply a new tag, e.g. RLS_TAG1a to rev
1.1 of all files.

The tricky one will be RLS_TAG2: some of the tags will be on the branch,
some on the trunk. You'll need to move any tags from the branch to the
trunk (again, instead of moving, create a new tag - that way, you can
always abandon the new tag if you make an error).

In future, don't use 'import' to populate your repository, unless it is
third-party source code.

- --
Jim Hyslop
Dreampossible: Better software. Simply.
                 Consulting * Mentoring * Training in
    C/C++ * OOD * SW Development & Practices * Version Management
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird -


reply via email to

[Prev in Thread] Current Thread [Next in Thread]