Strange symptom with cvs status when merge between branches

[Matthew Berney]

We are using a CVS pserver model with Linix Server and NT clients.  We are
running CVS v1.10.8.  

We have three branches in the repository:  IP2, IP3, R2_0

When we merge files between IP2 and IP3, then do a cvs status on R2_0, then
some of the files show up as "Needs Patch".  I am confused.  Why is the R2_0
branch effected by the merge operation when it wasn't even participating in
the merge?

Please reply via email since I am not on the discussion group.

Thanks,

Matt Berney
Oresis Communications


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Strange symptom with cvs status when merge between branches

[Matthew Berney]

The exact cvs commands in use are:

cvs up -r IP3  (update to the target branch)
cvs up -j Last_Merge_IP2 -j IP2(merge changes since last merge)

As you can see, the R2_0 branch is not even included here.  And yes, we are
sure that the "Last_Merge_IP2" is on the IP2 branch and not the R2_0 branch.

Any clues?



-Original Message-
From: Derek R. Price [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 16, 2001 12:28 PM
To: Matthew Berney
Cc: '[EMAIL PROTECTED]'; Fauzi Ashurex; John Raykowski
Subject: Re: Strange symptom with cvs status when merge between branches


Matthew Berney wrote:

> We are using a CVS pserver model with Linix Server and NT clients.  We are
> running CVS v1.10.8.
>
> We have three branches in the repository:  IP2, IP3, R2_0
>
> When we merge files between IP2 and IP3, then do a cvs status on R2_0,
then
> some of the files show up as "Needs Patch".  I am confused.  Why is the
R2_0
> branch effected by the merge operation when it wasn't even participating
in
> the merge?

What was the exact CVS command you used for the merge, and if you used 'cvs
up'
for the merge, are you certain you were merging to the branch you thought
you
were merging to?

Derek

--
Derek Price  CVS Solutions Architect (
http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
The advertisement is the most truthful part of the paper.

- Thomas Jefferson



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Interaction between cvs co and edit watches

[Matthew Berney]

We are using a CVS pserver model with Linix Server and NT clients.  We are
running CVS v1.10.8.  

I have discovered that using cvs co to checkout a new work area removes any
edit markings that may exist on a file.

For example:

cd c:\work\watch_test
cvs co -r mybranch myproj
cd myproj/mymodule
cvs edit myfile
cvs editors
myfilemberney Fri Feb 16 22:11:28 2001 GMTmberney
C:\work\watch_test2\myproj\mymodule

cd c:\work\watch_test2
cvs co -r mybranch myproj
cd myproj/mymodule
cvs editors
(BLANK)

As you can see from my simulated transcript here that when I checkout myproj
in a separate work area, the edit markings go away.

Is there any way to prevent this?  Or is there some other solution?

Please reply via email.

Thanks,

Matt Berney
Oresis Communications







___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Strange symptom with cvs status when merge between branches

[Matthew Berney]

Thanks for the info Derek.

Answer #1:  No IP3 and R2_0 are different branches in the repository

Answer #2:  Timing may have something to do with it, but I doubt it.
Nothing was happening on the R2_0 branch at the time of the merge.

If I do a cvs diff between the IP3 and R2_0 branch, there is no difference
in the source (other than the revision, of course :)  

If I do a cvs update, nothing happens; i.e. there is nothing to update.
But, the timestamp on the file changes to reflect the time the merge
occurred...very strange.

--Matt


-Original Message-
From: Derek R. Price [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 16, 2001 8:59 PM
To: Matthew Berney
Cc: '[EMAIL PROTECTED]'; Fauzi Ashurex; John Raykowski
Subject: Re: Strange symptom with cvs status when merge between branches


Matthew Berney wrote:

> The exact cvs commands in use are:
>
> cvs up -r IP3  (update to the target branch)
> cvs up -j Last_Merge_IP2 -j IP2(merge changes since last merge)
>
> As you can see, the R2_0 branch is not even included here.  And yes, we
are
> sure that the "Last_Merge_IP2" is on the IP2 branch and not the R2_0
branch.
>
> Any clues?

1)  IP3 is an alias for R2_0?
2)  Someone checked something into the R2_0 branch that had nothing to do
with
you but happened to happen at a similar time?

Have you tried CVS log to see what exactly CVS wanted to patch into your
R2_0?

Derek

--
Derek Price  CVS Solutions Architect (
http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
Metaphors be with you.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Problem tagging a large repository

[Matthew Berney]

Hello CVS gurus,

I am trying to manage the software configuration for a large team of
Software Engineers (60+) using CVS on Windows NT.  We are attempting to use
the "Flying fish approach" in the Open Source Development with CVS.  This is
essentially using personal branches to support parallel development.

We are having *severe* problems when multiple people try to tag the
repository simultaineously.  The repository is ~4GB and the cvs tag
operation takes about 15 minutes.  The problem is that Windows NT file
sharing mechanism interferes with CVS normal operation.  When one person is
tagging the repository, everyone else who tries to tag files gets file
sharing violations.  

Has anyone out there seen this behavior?  Do you have a solution?

Thanks,

Matt



Matt Berney Email: [EMAIL PROTECTED]
Software Test Engineer  Phone: 466-6278
Oresis Communications

RE: Keyword substitution during update

[Matthew Berney]

I was reading in the CVS Manual "Open Source Development with CVS", that the
update command has the -kMODE flag where:
  MODE is k to avoid keyword expansion.

So, to do an update without keyword expansion, do a "cvs update -kk"

Realize that the resulting updated file will not have the keywords expanded.
So the line containing your keyword would end up:
  $Version$

Regards,
Matt



Matt Berney Email: [EMAIL PROTECTED]
Software Test Engineer  Phone: 466-6278
Oresis Communications


-Original Message-
From: Martin Apel [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 27, 2000 8:20 AM
To: [EMAIL PROTECTED]
Subject: Keyword substitution during update


Hi, all

 

I have a problem updating files in a branch containing keywords.

Those files contain something like:

 

#Version:  $Revision: 1.10.4.1 $

 

before the update. Updating generates a conflict like the following:

 

<<< Rvr.make

#Version:  $Revision: 1.10.4.1 $

===

#Version:  $Revision: 1.12 $

>>> 1.12

 

This happens for the keywords Id, Date and Revision. When updating

the whole branch this leads to endless conflicts, I have to resolve by hand.

Does anybody know a way around this?

 

Martin



Martin Apel phone: ++49.6301.606.300
Human Modeling  fax:   ++49.6301.606.309
TECMATH AG  email: [EMAIL PROTECTED]
Sauerwiesen 2
67661 Kaiserslautern, Germany

RE: verification

[Matthew Berney]

There are many ways that this can be achieved with CVS.  One of the
administrative files "commitinfo" allows you to execute a script when the
commit operation occurs.  This is a "pre-commit" trigger.  You could
implement some sort of function to validate the files prior to checkin.

Another approach is to checkin on a branch and then merge the branch onto
the main.  If the merge and validation test is successful, then commit to
the main.  Otherwise, reject the merge request.

Matt


Matt Berney Email: [EMAIL PROTECTED]
Software Test Engineer  Phone: 466-6278
Oresis Communications


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Saturday, July 08, 2000 9:55 AM
To: Lukasz Michalski
Cc: [EMAIL PROTECTED]
Subject: Re: verification


[ On Saturday, July 8, 2000 at 14:14:38 (+0200), Lukasz Michalski wrote: ]
> Subject: verification
>
> I'm wondering if its possibile to moderate commits by some person(s). I
> mean when somebody commits something then it is verified by somebody
> else and then added to main tree. If "moderator" refuses the changes
> then commit fails and coder gets info what he must change.
> 
> Is it possibie with CVS?

It's a lot easier to do two-phase commits in a system designed with this
goal in mind, such as Aegis.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]>  
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>

RE: verification

[Matthew Berney]

There are many ways that this can be achieved with CVS.  One of the
administrative files "commitinfo" allows you to execute a script when the
commit operation occurs.  This is a "pre-commit" trigger.  You could
implement some sort of function to validate the files prior to checkin.

Another approach is to checkin on a branch and then merge the branch onto
the main.  If the merge and validation test is successful, then commit to
the main.  Otherwise, reject the merge request.

Matt


Matt Berney Email: [EMAIL PROTECTED]
Software Test Engineer  Phone: 466-6278
Oresis Communications


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Saturday, July 08, 2000 9:55 AM
To: Lukasz Michalski
Cc: [EMAIL PROTECTED]
Subject: Re: verification


[ On Saturday, July 8, 2000 at 14:14:38 (+0200), Lukasz Michalski wrote: ]
> Subject: verification
>
> I'm wondering if its possibile to moderate commits by some person(s). I
> mean when somebody commits something then it is verified by somebody
> else and then added to main tree. If "moderator" refuses the changes
> then commit fails and coder gets info what he must change.
> 
> Is it possibie with CVS?

It's a lot easier to do two-phase commits in a system designed with this
goal in mind, such as Aegis.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]>  
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>

RE: Cvswebedit needs to be made GPL/open source. Any volunteers?

[Matthew Berney]

Ok...now how does this pertain to CVS???  This discussion group is for
issues relating to CVS.  Please limit your posting to the perscribed
subject.  Take the griping and opinions about different open source
environments elsewhere.


Matt Berney Email: [EMAIL PROTECTED]
Software Test Engineer  Phone: 466-6278
Oresis Communications


-Original Message-
From: David Thornley [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 13, 2000 3:06 PM
To: [EMAIL PROTECTED]
Subject: Re: Cvswebedit needs to be made GPL/open source. Any
volunteers?


"Todd T. Fries" wrote:
> 
> On Thu, Jul 13, 2000 at 11:17:46AM -0700, Steve Arnold wrote:
> > In short, no, and it sucks. RS created the GPL precisely because the BSD
> > license was too restrictive. And the XFree86 guys use the GPL because
> > they didn't like the X license (again, too restrictive).
> 
> You are off base here.  X and BSD allow anyone to do anything with the
> source, GPL expressedly forbids anyone to do anything without releasing
it.

Actually, no.  Unless I am sadly mistaken, the GPL allows you to do
whatever you like to the software in private (the "consenting
programmers"
principle).  Once you decide to distribute it, the license takes
effect:  you must release it under the GPL and you must release the
modified source code.

> GPL is the more restrictive.  It is the freedom to 'do whatever' with the
> source that RS cannot stand, and thus you and his cronies continue to
> suggest that GPL is less restrictive, when in reality, it forces more
> restrictions.

Specifically, if I'm using code under the GPL, I'm prevented from
doing things that I could do if I were to use, for example, X code.
The GPL even points these things out:  there are programs that you
simply may not link with GPL-covered code and distribute.  I don't
believe this is the case with X code (provided you satisfy the
requirements for the code you're linking to).  (This is in
addition to the practical difficulty of using Gnu code in commercial
software.)

Now, the people at Gnu obviously think these restrictions are
reasonable, and that's fine with me.  I can use Gnu software
under the GPL or not at all, just like any other.  However, it is
a more restrictive license than X and BSD in terms of what
it allows me to do with software, and there's no point in
pretending otherwise.

-- 
David H. Thornley  Software Engineer
at CES International, Inc.:  [EMAIL PROTECTED] or (763)-694-2556
at home: (612)-623-0552 or [EMAIL PROTECTED] or
http://www.visi.com/~thornley/david/

RE: Switching branch to trunk, trunk to another branch

[Matthew Berney]

Sounds interesting.  It occurs to me that you could create the branch B at
the point in which you want to create the separate branch for your
consulting group.  Make sure that you apply a static tag at the Branch Point
in addition to the branch tag.

I recommend that you leave Branch A in place and then manage your repository
with two branchs: Branch A and Branch B.  There is no requirement that your
main line of development needs to be on the trunk.  And there are many
reasons why having code on the branch is desirable.


Matt Berney Email: [EMAIL PROTECTED]
Software Test Engineer  Phone: 466-6278
Oresis Communications


-Original Message-
From: Matt Hartfield [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 14, 2000 12:18 PM
To: info-cvs mailing list
Subject: Switching branch to trunk, trunk to another branch


Hi all,

This may be a newbie merge question, but I can't find anything in the
faqs or the docs that I've found on the web that can help me with this.

A few months ago, I branched a development version of our code off (call
this branch A).  We have continued development on both the main trunk
and on branch A.  At this point, the code that's sitting on branch A
should become the "primary version" of the code, i.e., the code that
gets checked out if someone says "cvs co module" with no revision tag. 
This means it needs to become the version of the code sitting on the
trunk.  The code that's at the current head revision of the trunk should
become a new branch (branch B) on which a separate thread of development
can continue.  From this point on we will have two versions of the code,
one for our in-house development group, and one for our consulting
group.  The consulting group's code is what's going to be on branch B. 
Occasionally changes will travel back and forth between the branches,
but for the most part they will be separate code bases.

If I look back at the history of files on the main trunk after I merge
branch A with the trunk, I'd like to see all of the revisions that
occurred on the branch, and not those that occurred in the main trunk
between branch A and branch B.  Similary, I'd like the revisions that
occurred on the main trunk between branch A and branch B to continue
with branch B.

Is there a way to essentially "rotate" the trunk 90 degrees around a
branchpoint, so that what's currently the trunk becomes a new branch and
what's currently a branch becomes the new trunk?  I suppose that one way
to do this is:

1) Create a new branch B at the same point as branch A.  Populate all
changes on the main trunk to the new branch (I don't know if there's a
way to do this with merge or not).

2) Populate all changes from branch A to the main trunk.  Again, it
would be nice if there's a way to do this with merge and maintain
history.

I'll play with cvs in a test repository some more to see if I can figure
this out, but any help would be greatly appreciated.

Thanks,
Matt

-- 
Matt Hartfield
Kivera, Inc.
[EMAIL PROTECTED]

RE: cvs + continuus

[Matthew Berney]

Hello,

My company is currently negotiating with Continuus as a possible replacement
for CVS.  One of the main reasons for the conversion are to add more
capability for parallel development on multiple branches simultaneously.
While you can do this with CVS, it is a manual process and requires many
wrapper scripts to support it.  Continuus has a full featured promotion
model with task-based CM to allow developers to insulate their work from
each other and a stable baseline.

I am curious about any experiences people have in migrating their repository
from CVS to continuus.  How did you do the switchover?  What is the size of
your development team?  These sorts of things.

Any information would be great.

Matt Berney
Senior Engineer
Oresis Communications, Inc.


-Original Message-
From: Ryan Hennig [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 24, 2000 3:47 PM
To: [EMAIL PROTECTED]
Subject: Re: cvs + continuus


It' s interesting to see a message about conversion from CVS to Continuus,
because the company I work for is currently trying to switch from Continuus
from CVS.  Does anyone on this list know of a tool that would facilitate
this
conversion?  I am trying to find some sort of conversion tool before
attempting to cook up my own Perl script to do it.

Ryan


Eugene Kramer wrote:

> Hi Nick,
>
> Continuus does use RCS as a backed storage format for archive files, but
> this is where similarities end. First of all, there is no branching inside
> these RCS files, all metadata is kept separately, in Informix. Also, only
> text files are kept with deltas in RCS files, all versions of binary files
> are kept as separate files.
>
> However, you should be able to migrate CVS repository to Continuus. It is
> possible to feed Continuus migration process with ,v RCS files, and it
will
> preserve revisions numbers during the migration. Preserving label
> information, submission comments and magic branches is another story, and
I
> am not ready to describe it now for I do not know the details. Ask me in a
> couple of months...
>
> Eugene.
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 22, 2000 7:33 PM
> To: [EMAIL PROTECTED]
> Subject: cvs + continuus
>
> Does anyone know anything about combining CVS and Continuus or even
> if this is possible. I am lead to bellieve that the internal file
> representations are the same.
>
> Any information woiuld be greatly appreciated.
>
> Thanks
> Nick Doan

RE: Lock a branch

[Matthew Berney]

The best way I know of to lock or protect a branch is the commitinfo file.
You can create a script that gets executed every time a commit operation is
performed.  Within that script, you could add any type of policy enforcement
you wish.  For example, in our organization, we have a "commit filter" that
executes every time a commit operation is performed.  

This script validates the branch and ensures that the person has permission
to check into the branch.

Hope this helps.

Matt


-Original Message-
From: Nhat Nguyen [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 06, 2000 2:53 PM
To: [EMAIL PROTECTED]
Subject: Lock a branch


Hi all,

Could someone tell me is there a way to lock a branch (instead of files) ? 

Thanks,

[EMAIL PROTECTED]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Steve Redlich
Sent: Wednesday, September 06, 2000 11:07 AM
To: [EMAIL PROTECTED]
Subject: CVS Advocacy Help


I am employed by a large aerospace company whose management has been
fooled by the sales staff at some of the large CM tools company.  [e.g.
Rational ClearCase and Continuus]  Does anyone have any CVS "sales"
material I could use to help persuade them otherwise?

Thanks,
Steve Redlich
[EMAIL PROTECTED]

cvs rtag vs cvs tag

[Matthew Berney]

Currently we do development on a branch and then merge individual changes
onto the branch.  We use a branch tag, lets call "codeline-branch".  Each
night, we perform a build and then tag the build with a static tag:
"codeline-static-DATE".

What is the difference between cvs rtag and cvs tag?  Should we be using
rtag in this case?  Under what circumstances do you use rtag instead of tag?

Thanks,

Matt

RE: Track the changes between the builds???

[Matthew Berney]

One of the global option for cvs is the -s VARIABLE=VALUE.  Look at page 155
in the Open Source Development with CVS manual. So, you could do something
like:

cvs -s BUGID=mybugid commit -m "I just fixed mybugid"  file.c

If your loginfo file contains a line:

  myproj /usr/local/bin/foo.pl ${=BUGID}

Then foo.pl script is invoked with 'mybugid' as an argument.  Armed with
this, you could easily add a script to associate bugids with specific
checkins.  Then the "meta-data" would be associated with the specific
revisions accessable to any greedy build miester.

Hope this helps,

Matt Berney


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 08, 2000 11:14 AM
To: [EMAIL PROTECTED]
Subject: Track the changes between the builds???


Ok, here is the deal.  I am a buildmaster in my company.  I am trying 
to track the BugID numbers that were submitted into the current build 
since the last build.  The way i build, consists of updating all the 
projects, tagging all the files with current-date-year-time and then 
extracting for the build...i just implemented the rcsinfo templates 
that allow developers to enter bugID at every commit...basically all 
i need to do is to run log -rtag: command where tag=the tag of the 
last build, redirect the output to a temp file and query for all the 
different bugID numbers...I was wondering if there is a different way 
of doing it???  or what is the more convinient point of the build 
process to call the log???  I was looking at taginfo...can the list 
be produced automatically while i am tagging the next build?  Any 
ideas or comments are greatly appreciate???  and other ways of going 
around the task???

all the help is greatly appreciated,
-Julia

RE: excluding subdirectories from update/commit ???

[Matthew Berney]

What is the requirement that you are trying to satisfy?  Why do you need to
exclude updates?

One way I can think of off the top of my head is to use static tags to
create a baseline.  Then when you update, you update to the specific tag
instead of the tip.  This gives you control over what revisions are included
when you update.  Developers then can checkin to the tip, but the build uses
the static baseline.  When you are ready to move the baseline, then you
select the revisions that you want included in the new baseline and apply a
new static tag.

Hope this helps,

Matt


-Original Message-
From: David Martin [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 10, 2000 9:17 AM
To: [EMAIL PROTECTED]
Subject: excluding subdirectories from update/commit ???


Here's what I'd like to do --

Suppose I have a simple hierarchy of directories a -- b -- c (that is, c
is a subdirectory of b, which is a subdirectory of a).  The entire
hierarchy has been checked out from CVS.

A team of developers is working on source code in directory b, and any
member of the team can do the normal CVS operations such as checkout,
update, and commit.  Source files in directory b are updated and
committed frequently.  

The files in directory c are MODIFIED frequently.  But I DO NOT want
them updated and committed every time someone does "cvs commit" or "cvs
update" in the b directory.  (I do want them updated and committed at
certain times, but those operations can be handled by a designated
repository administrator.)

My question is: Is there a good, reliable, bulletproof way to ensure
that directory c is ignored when updates and commits are performed in
directory b?

I know about the -l (local) option to commit and update.  But it's all
too easy for a team member to forget about using it, and I don't
consider the use of .cvsrc files to be a reliable way of enforcing the
use of -l.

I know about .cvsignore files, but they only apply to files that AREN'T
in the repository, and my files in directory c ARE in the repository.

I know about excluding files in module declarations, but as I understand
it, if a developer does this -- cd b ; cvs update -- then no module
declaration applies.

I think what I need is a file just like .cvsignore, but which causes CVS
to exclude the specified files from (at least) updates and commits.  

Or, does anyone know of a way to get this behavior, which I'm not aware
of?

Thanks in advance for any relevant information!

-- David Martin

RE: excluding subdirectories from update/commit ???

[Matthew Berney]

Ahh, indeed it is difficult to make changes to your build structure without
introducing other process changes in your environment.  This is always a
tricky area.  Agreed, changing the build structure such that the binaries
are located outside the source code hierarchy.  But, at times we neither
have the time nor the resources to address the root cause.  

Short of changing the directory structure, you could implement a commit info
script to avoid checking in files in the binaries directory except under
certain conditions.  Now, I don't know what your conditions are.  But, you
could come up with a list of conditions and implement that as a script.
Hook that into the commitinfo file only for the binaries directory...and it
just might work.


--Matt

-Original Message-
From: David Martin [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 11, 2000 3:10 PM
To: Matthew Berney
Cc: [EMAIL PROTECTED]
Subject: Re: excluding subdirectories from update/commit ???


Matt --

Thanks for your comments.

Matthew Berney wrote:

> What is the requirement that you are trying to satisfy?  Why do you need
to
> exclude updates?

The subdirectories, such as "c" in my example, contain binaries
corresponding to
the source code in their parent directories (such as "b").  We would like to
be
able to use CVS to make snapshots of the binaries at certain points in time,
but
we don't want the binaries to be updated or committed every time someone
runs
update or commit in the source code directory.

As I mentioned, I realize there are already some ways to prevent the updates
from applying to the binaries, but I'm looking for something that doesn't
place
any new constraints on the developers.  That is, no matter what form of
update
or commit command a developer wants to use, I'd like to ensure that it
doesn't
apply to the subdirectories containing the binaries.

I realize it would make sense just to move the binaries out of the source
code
hierarchy, and make our binary snapshots from the new location. But this
creates
some other complications, so -- as always -- I'm just looking for the
solution
with the greatest simplicity and the least overhead.

-- David


>
>
> One way I can think of off the top of my head is to use static tags to
> create a baseline.  Then when you update, you update to the specific tag
> instead of the tip.  This gives you control over what revisions are
included
> when you update.  Developers then can checkin to the tip, but the build
uses
> the static baseline.  When you are ready to move the baseline, then you
> select the revisions that you want included in the new baseline and apply
a
> new static tag.
>
> Hope this helps,
>
> Matt
>
> -Original Message-
> From: David Martin [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, September 10, 2000 9:17 AM
> To: [EMAIL PROTECTED]
> Subject: excluding subdirectories from update/commit ???
>
> Here's what I'd like to do --
>
> Suppose I have a simple hierarchy of directories a -- b -- c (that is, c
> is a subdirectory of b, which is a subdirectory of a).  The entire
> hierarchy has been checked out from CVS.
>
> A team of developers is working on source code in directory b, and any
> member of the team can do the normal CVS operations such as checkout,
> update, and commit.  Source files in directory b are updated and
> committed frequently.
>
> The files in directory c are MODIFIED frequently.  But I DO NOT want
> them updated and committed every time someone does "cvs commit" or "cvs
> update" in the b directory.  (I do want them updated and committed at
> certain times, but those operations can be handled by a designated
> repository administrator.)
>
> My question is: Is there a good, reliable, bulletproof way to ensure
> that directory c is ignored when updates and commits are performed in
> directory b?
>
> I know about the -l (local) option to commit and update.  But it's all
> too easy for a team member to forget about using it, and I don't
> consider the use of .cvsrc files to be a reliable way of enforcing the
> use of -l.
>
> I know about .cvsignore files, but they only apply to files that AREN'T
> in the repository, and my files in directory c ARE in the repository.
>
> I know about excluding files in module declarations, but as I understand
> it, if a developer does this -- cd b ; cvs update -- then no module
> declaration applies.
>
> I think what I need is a file just like .cvsignore, but which causes CVS
> to exclude the specified files from (at least) updates and commits.
>
> Or, does anyone know of a way to get this behavior, which I'm not aware
> of?
>
> Thanks in advance for any relevant information!
>
> -- David Martin

What is Cederqvist?

[Matthew Berney]

Pardon my ignorance, but what is the Cederqvist?  Is it a user manual, some
arcane CVS lore?  I have seen many references to it here on the CVS digest.
The
reference I use most frequently is "Open Source Development with CVS", by
Karl Fogel ([EMAIL PROTECTED]).

Matt

RE: Help Requested

[Matthew Berney]

This is certainly possible with CVS.  The key is to determine if you have
ever merged changes from the Branch Y back to the Main.  If so, then you
have to Join the changes between two points (two -j flags on the cvs
update).  The problem with CVS is that it doesn't keep track of the last
time you merged.  So you have to keep track of this with static tags.

If not, then you can simply update to the Main and join in the changes from
Branch Y.

1)  Update to the Main:
  cvs update -r Main

2)  Join the changes from Branch Y onto the Main branch
  cvs update -j branch_y

Another thing that you can do is use the -n command on the cvs command line
to "see what would happen if you execute the command".  This flag tells cvs
to execute the command, but don't really do it.  That way, you can be sure.
For example:

cvs update -r Main  (update to the Main)
cvs -n update -j branch_y  (see what would happen if you really executed the
command).

Hope this helps.

Matt

-Original Message-
From: Manoj Kumar Rana [mailto:[EMAIL PROTECTED]]
Sent: Saturday, September 16, 2000 10:10 AM
To: [EMAIL PROTECTED]
Subject: Help Requested


Hi, 

I am currently working on a Branch of a Branch of Main Tree, and I am
required to submit my changes to main tree now, without distrubing the
intermediate branch. I am new to using the CVS, and cannot experiment as
the time limit is very close, and I can not afford to make mistake.

For your understanding, I am explaining the problem graphically:

   Main_Tree>
|_.Branch X
|> Branch Y

Branch X is a stable release.. and I cannot change any files in that.
I am working on Branch Y.
I want to merge my changes to Main Tree.. which has gone heavily changed
after the Branch X. 

Please suggest  the way to do this.

Quick and reply containing commands are highly appreciated ..as I am a new
to CVS.
Though any slightest hint is also required and appreciated.

Thankx in advance.

Rana.

[Info-cvs] timezone settings for local time

[Matthew Berney]

It appears that CVS uses GMT for revision logs.  Is there any way (such as
TZ environment variable) to use local time instead?

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

[Info-cvs] Problem detected with missing files

[Matthew Berney]

We are in the process of converting over our repository from :local: on
Windows NT to :pserver: on Linux.  The repository was copied over and we
wrote a script to modify each person's existing work area to point to the
repository on the Linux server.  This script changes the CVS/Root file in
each directory.  Pretty simple script.

Everything worked fine except for one small problem.

If you remove a file, then cvs update to get it back, an error message is
generated:

-> cvs status Makefile
===
File: Makefile  Status: Up-to-date

   Working revision:1.136.48.11
   Repository revision: 1.136.48.11 /cvs/isis700/sw/Makefile,v
   Sticky Tag:  Beta-Work-0 (branch: 1.136.48)
   Sticky Date: (none)
   Sticky Options:  (none)

-> rm Makefile
rm: remove `Makefile', overriding mode 0444? y

-> cvs update Makefile
cvs [update aborted]: cannot find Makefile: No such file or directory

Any clues?

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Check out trigger

[Matthew Berney]

There is really no notion of checkout in CVS.  Rather, you edit the file and
then commit the changes to the repository.  You don't *have* to check the
file out.  You can simply make the file writable, modify the file, and
commit the changes.  

The cvs edit command may be what you want.  You can set "edit watches" in
your repository to activate a script (i.e. trigger) when someone marks a
file for edit.  Realize, however, that someone editing a file can "unedit"
the file rather than committing the changes.

Look into "watches".  This might do the trick.

Matt


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 26, 2000 11:49 AM
To: [EMAIL PROTECTED]
Subject: Check out trigger


Hello All,
  I am desperately trying to have a trigger set up for check 
out. What I have been able to do is to add the following line in the 
module file
mod2 -o d:\myprog mod2

And what this does is it will fire the 'd:\myprog' script whenever 
any file from module 'mod2' is checked out. 

But what I am looking for is to have a trigger which will be called 
whenever any file is checked out from any module in the repository.

All thoughts regarding this will be sincerely appreciated. 

I am running CVS 1.10.5 on NT 

Waiting for some ideas,
Anand


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Project Mgmt Integration

[Matthew Berney]

Here's a perl script that uses cvs history and cvs annotate to measure the
rate of change on a codebase.  Executing this tool generates:
  -- the list of files that were modified on a daily and weekly basis
  -- the number of lines in each source file
  -- the number of lines changed per day in each source file
  -- the number of lines changed per week in each source file
  -- total number of source lines in files changed
  -- total number of lines changed per day
  -- total number of files changed per week.

All of this data is output in an HTML file for easy browsing.  I have a
cronjob that updates a work area each day and then runs the tool.

Hope this helps,

Matt





-Original Message-
From: Ken Riley [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 25, 2000 6:36 PM
To: CVS-List
Cc: Karl Fogel
Subject: Project Mgmt Integration


Hey all,

We've just completed the migration from the hated MS VSS to CVS. I'm
thrilled, my developers are happy, yippee!

I have only one more wish--to find a Perl widget that will integrate with
CVS and do things like track the growth of a project using metrics like
lines of source code or, better, function points (not likely given that we
do SQL and Web development). Any one know of something?

Thanks in advance,

Ken

-
  Ken Rileyo: 512.416.8000 ext 124
  [EMAIL PROTECTED]  h: 512.444.2650
  [EMAIL PROTECTED]  m: 512.750.4959
  (sends mail to my phone)

 PGP Key Available at:
   


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs


 countChanges.pl

Isolating baseline from checkins

[Matthew Berney]

In our current environment, we have a problem maintaining a stable baseline.
The problem is that everyone checks into the tip and then we build from the
tip.  Then we have to sort everything out afterwards.

A few approaches have been considered (personal branches, and static tags).
Branches would work, but they are complicated to keep up-to-date.  Static
tags on the other hand, are simpler, but how do you handle two people
tagging different revisions of the same file?

Looking at this problem from a build point of view:
  1)  Apply a static tag to the entire repository (this is our baseline)
  2)  Developers tag the individual files that they work on
  3)  Update to the baseline + developer's tag.

Are there any scripts out there to help a developer keep track of the files
being worked on.  For example, looking at this problem from the developer's
point of view:
  1)  Update to the baseline
  2)  Update "my files" to the tip
  3)  When ready to "integrate" changes to the baseline, tag "my files".

How do people use CVS in a large organization?  How do you isolate the
baseline from developers checkins?

Thanks in advance,

Matt


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS timestamps

[Matthew Berney]

I find it hard to believe that a tool that works across multiple timezones
does not support a way to localize the timestamps?  Why not use the TZ
environment variable?  This is pretty standard isn't it?  It would be nice
to have the timestamps in the repository actually match our local time.

Matt


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 05, 2000 12:21 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: CVS timestamps


Noel K writes:
> 
> I am having the problem with the CVS timestamps being off by several 
> hours. I did a search and read through many of the threads on this 
> subject, so I know that CVS stores the time in GMT (or UTC - by the 
> way, is UTC the European equivalent term for GMT?)

Not quite; UTC is the modern, official International Standard time that
roughly corresponds to the old de-facto standard that was GMT.  Now, GMT
is just a civil time used in the UK (like Eastern Time or Pacific Time
in the USA) that has been redefined as UTC.  For more details, see
http://www.rog.nmm.ac.uk/leaflets/time/time.html.

> What I need to know is how to fix this so that the timestamp in the 
> CVS repository is the local time, not the GMT. 

It's not broken, so there's nothing to fix.  Keeping track of times in
UTC is the only practical way for CVS to support developers in different
time zones.

-Larry Jones

I think grown-ups just ACT like they know what they're doing. -- Calvin

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS timestamps

[Matthew Berney]

Agreed.  The server should save whatever time is necessary.  UTC seems
reasonable as it is global.  For open source repositories, this makes sense.
>From a user's perspective, I don't care if it is done on the server or the
client.  When I look at the revision history, (i.e. cvs logs, cvs history,
cvs status, etc.), it would be nice to relate this to "my" time.

A perfect example of this...I have a perl script which uses cvs history and
cvs annotate to keep track of the rate of change in our repository.  This
tool is always 8 hours off.  So, anyone who checks in their code after
2:00PM, the recorded change for cvs history purposes is the next day.

Matt

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 05, 2000 1:41 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: CVS timestamps


Matthew Berney writes:
> 
> I find it hard to believe that a tool that works across multiple timezones
> does not support a way to localize the timestamps?  Why not use the TZ
> environment variable?  This is pretty standard isn't it?  It would be nice
> to have the timestamps in the repository actually match our local time.

Localizing the timestamps in the user interface would be eminently
reasonable.  In fact, CVS already does that for input: any place you can
input a timestamp to CVS, it's assumed to be in local time unless you
specify otherwise.  Unfortunately, doing the same for output would
require a complete overhaul of the client/server protocol since it is
currently the server that converts timestamps into human-readable
strings but only the client knows the rules for converting UTC into
local time.  It might actually be possible to do without changing the
protocol by making use of tagged text, but it would still require a lot
of code changes.  If anyone is looking for a worthwhile and challenging
project, I'd say this would be a good one.

On the other hand, localizing the timestamps in the repository doesn't
make any sense.  Most civil times are not suitable for use as
timestamps; many jurisdictions have some form of daylight saving or
summer time which typically results in a one hour gap of non-existant
times in the spring and a similar period of duplicated times in the
fall.  The only way to deal with this would be to store the prevailing
time standard along with the local time, in which case you might as well
just store UTC and be done with it.  Not to mention the problem of
determining exactly which local time is *the* local time to be stored:
The server's?  The client's?  *Which* client?

-Larry Jones

This sounds suspiciously like one of Dad's plots to build my character.
-- Calvin

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Lock a branch

[Matthew Berney]

Use the cvs admin -l.  This will lock the latest revision on
that branch.


-Original Message-
From: Nestor Edelman [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 12, 2000 10:11 AM
To: [EMAIL PROTECTED]
Subject: Lock a branch


Hi there!
Does anyone have a script to lock a CVS branch to be used with
commitinfo?
I started to write one, but my boss wants one in place ASAP.
Please, help.
Thanks



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

What does "Emptydir" mean?

[Matthew Berney]

We are having problems with a set of files that are checked into the
repository.  We are having difficulty checking them out.  Below is the cvs
log from one of the files.  We are using CVS Server 1.10.8 on a Linux Redhat
6.2 server with NT clients using pserver.

After reviewing the manual, I couldn't find any reference to Emptydir.  Can
someone please explain it to me?  What do we have to do to recover?

==
memoryTrace> cvs log Makefile

RCS file: /cvs/CVSROOT/Emptydir/memoryTrace/Attic/Makefile,v
Working file: Makefile
head: 1.1
branch:
locks: strict
access list:
symbolic names:
Beta-ejohannes-19: 1.1.0.2
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:

revision 1.1
date: 2000/10/09 22:16:14;  author: ejohannes;  state: dead;
branches:  1.1.2;
file Makefile was initially added on branch Beta-ejohannes-19.

revision 1.1.2.1
date: 2000/10/09 22:16:14;  author: ejohannes;  state: Exp;  lines: +112 -0
Initially added on branch Beta-ejohannes-19

=

memoryTrace> cvs status Makefile
===
File: Makefile  Status: Up-to-date

   Working revision:1.1.2.1
   Repository revision: 1.1.2.1
/cvs/CVSROOT/Emptydir/memoryTrace/Attic/Makefile
,v
   Sticky Tag:  Beta-ejohannes-19 (branch: 1.1.2)
   Sticky Date: (none)
   Sticky Options:  (none)


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

How to get rid of sticky options

[Matthew Berney]

Somehow, (I know it's my fault, but let's ignore that), the -kb sticky
option is set on a text file in my repository by mistake.  Now, cvs can't
merge my file correctly because it think the file is binary.  How do I get
rid of the sticky option.  I looked at all the cvs admin -kMODE options.
But, there is no way to "turn off" the sticky option.  

Can someone please help?

Thanks,

Matt


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: How to get rid of sticky options

[Matthew Berney]

Thanks.

I thought I had tried the cvs admin -kkv, but it didn't work...exactly.  I
was able to get rid of the sticky option.  But, it wasn't straight forward.
Essentially, I had to do remove the sticky option with the 'cvs admin -kkv'
command, then 'cvs update -A' to remove all sticky tag information.
Executing the 'cvs admin' command or 'cvs update' command by itself was not
sufficient.

If you are interested in the complete sequence, keep reading.  Otherwise,
stop here.

CVS Version: 
1.10.8 (client):Windows NT
1.10.8 (client/server): Linux, Redhat 6.2

Repository: C:\cvs\repository (test repository)
Test File:  C:\cvs\work\testing\abc


1.  Obtain status of file; verify Binary option flag is set:

% cvs status abc
cvs status abc
==
File: abc   Status: Up-to-date

   Working revision:1.1.2.7 Fri Oct 27 23:59:09 2000
   Repository revision: 1.1.2.7 c:/cvs/repository/testing/abc,v
   Sticky Tag:  codeline (branch: 1.1.2)
   Sticky Date: (none)
   Sticky Options:  -kb

2.  Reset any sticky tags, dates, or '-k' options.

% cvs update -A abc
U abc
% cvs status abc
==
File: abc   Status: Up-to-date

   Working revision:1.1 Fri Oct 27 23:59:23 2000
   Repository revision: 1.1 c:/cvs/repository/testing/abc,v
   Sticky Tag:  (none)
   Sticky Date: (none)
   Sticky Options:  -kb *** NOTICE THE -kb FLAG IS STILL SET ***

3.  Reset the sticky options

%  cvs admin -kkv abc
RCS file: c:/cvs/repository/testing/abc,v
done
% cvs status abc
==
File: abc   Status: Up-to-date

   Working revision:1.1 Fri Oct 27 23:59:23 2000
   Repository revision: 1.1 c:/cvs/repository/testing/abc,v
   Sticky Tag:  (none)
   Sticky Date: (none)
   Sticky Options:  -kb *** NOTICE THE -kb FLAG IS STILL SET ***
% cvs update -A abc
U abc
% cvs status abc
==
File: abc   Status: Up-to-date

   Working revision:1.1 Fri Oct 27 23:59:57 2000
   Repository revision: 1.1 c:/cvs/repository/testing/abc,v
   Sticky Tag:  (none)
   Sticky Date: (none)
   Sticky Options:  (none)


-Original Message-
From: Mike Castle [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 27, 2000 2:56 PM
To: 'CVS Discussion Group'
Subject: Re: How to get rid of sticky options


On Fri, Oct 27, 2000 at 01:57:37PM -0700, Matthew Berney wrote:
> But, there is no way to "turn off" the sticky option.  

cvs admin -kkv ?

mrc
-- 
   Mike Castle   Life is like a clock:  You can work constantly
  [EMAIL PROTECTED]  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
We are all of us living in the shadow of Manhattan.  -- Watchmen

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs