Discussion:
s the cvs status always shows tags in ordered?
hezjing
2009-02-25 09:34:58 UTC
Permalink
Hi
The output of cvs status -v . looks like the following:

Existing Tags:
E (revision: 1.1.1.1)
D (revision: 1.1.1.1)
C (branch: 1.1.1.1.6)
B (revision: 1.1.1.1)
A (revision: 1.1.1.1)

Is the order of the tags guaranteed? That is the latest created tag will be
displayed on top, and the oldest one displayed at the bottom?

I'm trying to automate a process where the user input a tag name, the
program will find the "previous" tag and do a cvs diff between the two tags.
For example, if the user enter tag E, then the program should cvs diff tag E
and D automatically.
--
Hez
Larry Jones
2009-02-25 14:46:13 UTC
Permalink
[...]
Post by hezjing
Is the order of the tags guaranteed? That is the latest created tag will be
displayed on top, and the oldest one displayed at the bottom?
No.
--
Larry Jones

My brain is trying to kill me. -- Calvin
Michael Haggerty
2009-02-26 04:20:58 UTC
Permalink
[...]
Post by hezjing
Is the order of the tags guaranteed? That is the latest created tag will be
displayed on top, and the oldest one displayed at the bottom?
No.
That's unfortunate.

In my experience, it seems to be that typically the ordering *is*
preserved. Indeed, we use this assumption to help the heuristics that
choose symbol parents in cvs2svn; e.g., the decision of whether branch
1.5.2.7.4 was applied to branch 1.5.2 or 1.5.2.7.2 (or even 1.5.2.7.6,
which can happen if branch 1.5.2.7.4 was created, deleted, then
recreated). Resolving this ambiguity is a big headache for cvs2svn and
the apparent reverse-chronological ordering of symbols was one of the
straws that I grasped at.

Larry, do you know of specific situations where the symbol ordering is
not preserved, or are you just reluctant to guarantee that it won't
happen in the future?

I would also like to encourage CVS developers *not* to disturb the
ordering gratuitously :-)

Michael
Amaresh Chandra Das
2009-02-26 05:24:18 UTC
Permalink
hi,


Please use this,

#!/bin/sh

patterns=(
'?'
'Locally Added'
'Locally Modified'
)

for i in "${patterns[@]}"
do
cvs -Q status -R . | grep -i "$i"

use this link:- "http://www.freshblurbs.com/cvs-status-one-svn-bash-script"


done



Cheers
Amaresh [image: cid:***@01C94FB6.D222FBC0]

+91-9886720068

--- On *Thu, 26/2/09, Michael Haggerty <***@alum.mit.edu>* wrote:

From: Michael Haggerty <***@alum.mit.edu>
Subject: Re: s the cvs status always shows tags in ordered?
To: "Larry Jones" <***@siemens.com>
Cc: "hezjing" <***@gmail.com>, info-***@nongnu.org
Date: Thursday, 26 February, 2009, 9:50 AM
[...]
Post by hezjing
Is the order of the tags guaranteed? That is the latest created tag
will be
Post by hezjing
displayed on top, and the oldest one displayed at the bottom?
No.
That's unfortunate.

In my experience, it seems to be that typically the ordering *is*
preserved. Indeed, we use this assumption to help the heuristics that
choose symbol parents in cvs2svn; e.g., the decision of whether branch
1.5.2.7.4 was applied to branch 1.5.2 or 1.5.2.7.2 (or even 1.5.2.7.6,
which can happen if branch 1.5.2.7.4 was created, deleted, then
recreated). Resolving this ambiguity is a big headache for cvs2svn and
the apparent reverse-chronological ordering of symbols was one of the
straws that I grasped at.

Larry, do you know of specific situations where the symbol ordering is
not preserved, or are you just reluctant to guarantee that it won't
happen in the future?

I would also like to encourage CVS developers *not* to disturb the
ordering gratuitously :-)

Michael




Thanks & Regards,

Hare Krishna.....
à€®à€š à€®à¥‡à€°à€Ÿ à€®à€‚à€Šà€¿à€° à€¹à€°à¥€ à€®à¥‡à€°à¥€ à€ªà¥‚à€œà€Ÿ
à€¹à€°à¥€ à€žà¥‡ à€¬à€¡à€Ÿ à€šà€¹à¥€ à€•à¥‹à€ˆ à€Šà¥‚à€œà€Ÿ

Amaresh Chandra Das
Mobile: 91-9886720068
Mail: ***@gmail.com
***@in.com

"Walk with a hope in your heart....you will never walk alone"
Larry Jones
2009-02-26 15:16:07 UTC
Permalink
Post by Michael Haggerty
Larry, do you know of specific situations where the symbol ordering is
not preserved, or are you just reluctant to guarantee that it won't
happen in the future?
Lots of people have repository files that were originally created with
RCS rather than CVS, and some people even continue to use RCS on CVS
repository files. I have no idea whether RCS uses the same order as CVS
or not, I'm not even sure that CVS has always used the current ordering,
and I'm certainly not willing to guarantee that it won't change in the
future since there are good reasons to use a more sophisticated data
structure than a sequentially searched linear list. The RCS file format
doesn't guarantee any order so you shouldn't rely on one.
--
Larry Jones

Oh, what the heck. I'll do it. -- Calvin
Michael Haggerty
2009-02-27 09:46:45 UTC
Permalink
Post by Larry Jones
Post by Michael Haggerty
Larry, do you know of specific situations where the symbol ordering is
not preserved, or are you just reluctant to guarantee that it won't
happen in the future?
Lots of people have repository files that were originally created with
RCS rather than CVS, and some people even continue to use RCS on CVS
repository files. I have no idea whether RCS uses the same order as CVS
or not, I'm not even sure that CVS has always used the current ordering,
and I'm certainly not willing to guarantee that it won't change in the
future since there are good reasons to use a more sophisticated data
structure than a sequentially searched linear list. The RCS file format
doesn't guarantee any order so you shouldn't rely on one.
Thanks for the caveats. Like I said, we don't *rely* on the order per
se; we just use it as part of a heuristic for choosing one branching
topology from the many possibilities that are consistent with the data
recorded in the CVS repository. If the symbol order is screwed up, we
would still produce a correct conversion, albeit one that is more
complicated than "optimal".

So the fact that you don't seem to know of specific order-scrambling
tools is good enough for me :-)

Michael

Arthur Barrett
2009-02-26 21:38:11 UTC
Permalink
Hez,
Post by hezjing
E (revision: 1.1.1.1)
D (revision: 1.1.1.1)
C (branch: 1.1.1.1.6)
B (revision: 1.1.1.1)
A (revision: 1.1.1.1)
Is the order of the tags guaranteed?
It is not in the spec - so it is implementation specific, so different
flavours/versions of CVS/DCVS/OpenCVS/CVSNT may do different things.
Post by hezjing
That is the latest created tag will be displayed
on top, and the oldest one displayed at the bottom?
Generally as a rule I think the servers will send the results in the
order that they were added to the RCS file, which IS NOT the same as the
oldest to newest since a tag can be "moved" so its revision will change
but not its order in the RCS file.
Post by hezjing
I'm trying to automate a process where the
user input a tag name, the program will find
the "previous" tag and do a cvs diff between
the two tags.
For example, if the user enter tag E, then the
program should cvs diff tag E and D automatically.
If you explain WHY you want this - what the business objective is then
someone can probably help.

CVS was written over 22 years ago and is used by countless people for
running their business of software change and configuration management -
it is very very unlikely that you are so unique that the feature you
require has not been already implemented and used by countless others.

Instead of specifying the technical feature you require - instead
explain the business objective, eg:

BAD: find previous tag name
GOOD: compare the source code for this release with the source code for
the most recent (chronological) release and provide list of comments for
incorporating into release notes

Back to the technical: one drawback of CVS is that tags do not have a
date or a history, so generally you need to convert a tag to a
branch/date combination then use that.

Regards,


Arthur Barrett
--
Hez
Arthur Barrett
2009-02-27 02:12:24 UTC
Permalink
Hez,
We always tag the entire module for every
maintenance release.
Currently, the developer will fix the bug, tag
the entire module and then create a package containing
only the modified files.
The problem is in some cases, the developer will miss
some files in the package.
To avoid this problem, we are planning to automate
The developer will specify the tag's name of the release
he has created, and the program will package all the
modified files by cvs diff the latest two tags.
With the same program, we can always re-create a
package for a previous release.
For example while the latest release is 1.8, we
want to re-create a package for 1.2.
So we are figuring how to find the previous tag to do the cvs diff ...
The simple answer is that the automated program should track the last
time it was ran, and instead diff from that date to the user specified
tag. Of course it could just as easily track the last tag it used and
use that. Your automated program is going to need to store something
eventually - if it stores it in a text file it can then even version it
using CVS...

We (and many others) encountered similar business problems (release
tracking), and added specific features to CVSNT (free/unix just like
CVS) to assist with this. Tags are not suitable for tracking changes
since they identify a revision not a range of revisions, so CVSNT has
user defined change set ids (also known as bug ids) that can exist on
many revisions of many files. CVSNT then allows you to merge using
these bug ids or report on them using the audit database. We combine
the bug ids with promotion levels - a special branch that we merge
releases on to based on change sets.

Im sure others on the newsgroup will reply with the ways they have
addressed the same problem.

Regards,


Arthur
--
Hez
Loading...