RE: "cvs commit" features

[Reinstein, Shlomo]

It doesn't have to be so bad if it takes care of your "ignore" settings as
well. I think such an option may be good, at least for someone who did a
large re-org of the files in the project. However, I agree with Greg A.
Woods that the place of such options is not CVS itself but rather wrappers
of CVS or GUIs.

Shlomo

-Original Message-
From: Mike Ayers [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 09, 2002 8:48 PM
To: Reinstein, Shlomo
Cc: '[EMAIL PROTECTED]'
Subject: Re: "cvs commit" features


Reinstein, Shlomo wrote:

> Of course, a user can always use "cvs add" and "cvs remove" to add or
remove
> files, but these two options can help him/her make sure they didn't forget
> to do this for some of the files.

This is one of those things that might work really well, but only
for 
certain development models.  For instance, I am using a GUI based 
tool.  It likes to create lots of files that may or may not need to be 
archived.  I have experimentally determined that if I archive a 
certain set of them, then there seems to be no problems.  Do I want 
CVS to pester me about the ones I'm not archiving every time I do a 
commit in that directory?  No way!

And just think what would happen if you inadvertently did your CVS 
commit without making clean first...

Nannyware sucks.

Optional nannying?  Hmmm - doesn't the nannyware model *require*
that 
the nagging not be optional?


/|/|ike



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

Re: "cvs commit" features

[Fabian Cenedese]

>>Of course, a user can always use "cvs add" and "cvs remove" to add or remove
>>files, but these two options can help him/her make sure they didn't forget
>>to do this for some of the files.
>
> This is one of those things that might work really well, but only 
> for certain development models.  For instance, I am using a GUI based 
> tool.  It likes to create lots of files that may or may not need to be 
> archived.  I have experimentally determined that if I archive a certain 
> set of them, then there seems to be no problems.  Do I want CVS to pester 
> me about the ones I'm not archiving every time I do a commit in that 
> directory?  No way!

In my application which takes the output of cvs the user can choose between
add, remove and ignore the file. If ignore is selected the name is written into
the .cvsignore file so next time cvs won't ask about it again.

bye  Fabi





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

Is CVS usable for big companies/projects (HELP!!!)

[Ralph Jocham]

Hi All,
I am trying to convince upper level management that
CVS is a good
choice as a version control system. Their main contra
argument is that
it does not scale.
So, can you please give me some real world experiences
on which big
projects you used it. (Number of people, lines of
code, distributed,
...)
Also, names of well known companies CVS would help. (I
think NASA is one, but I am not sure)

With these numbers at hand I hope that I can convince
them.

Please reply ;)

Thanks,
Ralph

__
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com


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

Re: Tag locking change

[Paul Sander]

>--- Forwarded mail from [EMAIL PROTECTED]

>Paul Sander wrote:

>> I claim that "y" == "now" is a common special case.  Therein lies the
>> "tag the head of a branch" issue.

>   It is an *uncommon*  special case.  In every other case, the tagger 
>has an honest chance of knowing what they're tagging (in fact, darn 
>well *ought* to know what they're tagging).  It is not reasonable to 
>assume that one knows the state of the archive at the moment one hits 
>the return key.

It is perfectly reasonable when spawning feature branches from maintenance
or integration branches.  It is also perfectly reasonable when it's
necessary to remember stable implementations of subsets of features without
regard to the state of newer features undergoing active development.  I
contend both are frequently done.

>--- End of forwarded message from [EMAIL PROTECTED]



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

Re: Tag locking change

[Paul Sander]

>--- Forwarded mail from [EMAIL PROTECTED]

>[ On Wednesday, October 9, 2002 at 10:13:42 (-0700), Paul Sander wrote: ]
>> Subject: Re: Tag locking change
>>
>> There are lots of cases where someone demands "tag branch x as of time y".

>What the heck does that have to do with tagging the head of a branch?!?!?!?

Gosh, Greg, if you'd finished reading that paragraph and the next, you
would have the answer.  Let me recap here:

-->There are lots of cases where someone demands "tag branch x as of time y".
-->It's used often enough when someone doesn't care what the specific version
-->numbers are, or they don't know or care what tags (if any) have been
-->applied to those versions.  But they know what features they want, and
-->they know when those features were committed to the branch, so the
-->branch/timestamp pair is their means of identifying specific configurations.
-->In some shops that apply tags infrequently, this may indeed be the only
-->means to identify a configuration.

-->I claim that "y" == "now" is a common special case.  Therein lies the
-->"tag the head of a branch" issue.

Let me be more explicit:  The last version committed to a branch before
now is the head of the branch.  In other words, "branch x as of time now"
is the head of branch x.  Hence, the demand to "tag branch x as of time now"
is exactly the same as "tag the head of branch x".

>>  The proposed change to the locking system opens
>> a race condition between rtag and commit, where the head of the branch
>> can change while the tag is being applied.

>The point is you shouldn't be tagging the head of the branch without
>doing so from within a working directory which is up-to-date to the head
>of the branch in the first place.  It really doesn't matter whether "cvs
>rtag" makes it a safe "atomic" operation or not.

The only reason to have the working directory is to produce an inventory
of revision numbers of each version to which the tag is applied.
I claim that a branch/timestamp pair is equivalent to a revision number
in that it is another means to specifically identify versions.  The
reason this is true is because the version checked in on "branch x at
time y" has at most one revision number.

Determining the proper timestamp can be tricky, but so can be determining
the proper revision numbers.  Either way, the configuration needs to
be tested for correctness.  How that is done is beyond the scope of this
forum, but there are lots of ways to do it regardless of the method used
to identify the configuration.

>> However, assuming a timestamp of "now" during rtag is a low-overhead and
>> lock-free method to remove the race condition.

>Well, yes, in the implementation "now" hopefully gets converted to the
>time at the start of the command and doesn't change as the procedure
>progresses, and so it's a silly cheap trick to still get undefined
>results with the tag

Yes, that's how I recommended the implementation be done.

However, keep in mind that your notion of "undefined" means that you don't
know the specific revision numbers of each version that gets the tag.
But the following streams of commands are exactly equivalent (assuming
rtag were modified to accept both -D and -r options):

cvs checkout -r branch module cvs rtag -D now -r branch module
cvs tag label

No doubt you'll cry "foul" here because the checked-out working copy was
never validated.  In this case it doesn't matter because the desired
revisions are defined to be whatever's on the head of the branch at the
time the process is initiated.

Now let's try something else:

cvs checkout -r branch modulestamp=`date`
test awaycvs export -D $stamp -r branch module
cvs tag labeltest away
 cvs rtag -D $stamp -r branch module

I think that you will agree that these are equivalent, with the following
deviation:  One workspace contains CVS meta-data and the other does not.

Now consider that someone else checks out and tests a series of
configurations and produces a list that identifies "good" configurations.  
Such a list could contain existing workspaces that contain CVS meta-data,
it could identify an inventory of version numbers (e.g. the output of
"cvs status" reduced to some usable format), or it could supply
branch/timestamp pairs collected when the test environments were assembled.
All of these are equivalent and produce identical results.  What's more,
if all of the timestamps are identical, then a single branch/timestamp
pair can specify the entire configuration.

Now here's where the branch/timestamp method breaks down:

cvs checkout -r branch module
test away/failure
cvs update -r branch submodule
test away/good
cvs tag label

Under these conditions, there is no single branch/timetamp pair that can
identify the correct revisions of the entire module.  I believe that
Greg's argument is based on the notion that this is a common scenario.

But there are ways 

Re: Tag locking change

[Mike Ayers]

Adam Bregenzer wrote:

> Not at all.  The server that holds the cvs repository also has apache
> runing on it.  When a commit occurs each file that is committed is
> copied into a seperate directory.  That directory is the DocumentRoot
> for apache.  That way, when a change is committed it is automagicall
> viewable by browsing to the cvs server.  The point is that one who does
> not edit the site manages and approves the site.  Currently that
> individual runs cvs rtag when the site is in a producation ready state. 
> Then a script is run that does a cvs export with that tag and posts it
> to the live site.  It has nothing to do with the client, it's all
> *server* side.  I see no reason for it to bve tied to an update, I don't
> even know how to execute a server-side script on update and wouldn't
> want to anyways.

At this point I begin to understand what you are talking about.  What 
you are doing is overloading CVS to be an archiving system *and* 
distribution system.  This is, to be blunt, bad engineering.  What you 
should do is write a script which commits the file and, upon 
successful commit, updates DocumentRoot (or it could be a smart script 
that only updates the relevant directory).  So you already *do* have a 
working copy, you've just built it the wrong way.


/|/|ike




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

Re: Tag locking change

[Jenn Vesperman]

On Thu, 2002-10-10 at 05:40, Adam Bregenzer wrote:
> On Wed, 2002-10-09 at 14:58, Greg A. Woods wrote:
>
> > My point was that you can do the same thing more reliably with a "cvs
> > update" in a working directory that is the DocumentRoot.
> But then it wouldn't be automagic, it would be whenever cvs update is
> run.  Certianly every minute would be 'acceptable' but this solution is
> fine.  Plus in this case the repository and the live site have different
> directory structures.


Try a *info script like:

cd /wherever
/usr/bin/cvs -d cvs:/home/cvs export -r $1 whosiwhatsit
if [ $? -eq 0 ]; then
cd whosiwhatsit
/usr/bin/make
/usr/bin/make install
else
echo "Export failed."
fi  


$1 is obviously a tag. :)

You can use update instead of export, and -D now instead of -r $1 if you
want. You may also want to replace the echo with a mail.

The make and the make install should contain whatever is necessary to do
your build and/or rearrange the structure.


Jenn V.
-- 
"Do you ever wonder if there's a whole section of geek culture 
you miss out on by being a geek?" - Dancer.

[EMAIL PROTECTED] http://anthill.echidna.id.au/~jenn/




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

Re: Tag locking change

[Jenn Vesperman]

On Thu, 2002-10-10 at 04:26, Adam Bregenzer wrote:
> It has nothing to do with the client, it's all
> *server* side.  I see no reason for it to bve tied to an update, I don't
> even know how to execute a server-side script on update and wouldn't
> want to anyways.

> While there
> are several better ways to do it and you probably can't run an rtag
> command from a script run from a *info file it is an example.

You can run any cvs command from a script run from a *info file. Just
make sure the command is backgrounded so you don't have locking
conflicts.


Jenn V.
-- 
"Do you ever wonder if there's a whole section of geek culture 
you miss out on by being a geek?" - Dancer.

[EMAIL PROTECTED] http://anthill.echidna.id.au/~jenn/




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

Re: Tag locking change

[Greg A. Woods]

[ On , October 9, 2002 at 15:40:35 (-0400), Adam Bregenzer wrote: ]
> Subject: Re: Tag locking change
>
> On Wed, 2002-10-09 at 14:58, Greg A. Woods wrote:
> > 
> > My point was that you can do the same thing more reliably with a "cvs
> > update" in a working directory that is the DocumentRoot.
> 
> But then it wouldn't be automagic, it would be whenever cvs update is
> run.  Certianly every minute would be 'acceptable' but this solution is
> fine.  Plus in this case the repository and the live site have different
> directory structures.

There are many many many uncountable trivial and not so trivial ways to
make it "automagic" without having to simply run "cvs update" from cron
every minute.  Use a little imagination!

> > You could trigger the server-side "cvs update" in any number of ways,
> > though the very best would be if the individual doing the testing and
> > approving did it just before testing.
> 
> It's primarially for the developers, the testers only see it at
> regularly scheduled intervals so a developer's commit doesn't fsck
> something up.  The environment on the cvs server emulates the live
> environment, most developer machines do not that is the reason for the
> constant sync with cvs, immediate testing

So?  Developers could trigger the "cvs update" of whatever test system's
DocumentRoot they use just as easily too!

>  Plus, I don't want to
> give testers access to the test server and I don't want to write an
> interface for them to do it.

That's no excuse and it doesn't strengthen your argument one bit.

> What if
> you don't want or need to have a working copy?

If you're doing testing like this then you _NEED_ to have a working
copy!  It's no different than doing baseline builds with "regular"
source code.

>  You cannot really do
> anything in cvs without a working copy, which is obviously something
> some people on this list have not realized.

Well, "Duh!"   :-)

>  The fact that what I said
> doesn't make sense is a reflection upon you of the design and
> methodology in cvs.  Ya know not everybody wants a working copy

It doesn't matter what they "want".  They could want the moon, but they
can't have it.  This is the way CVS works, whether anyone likes it or
not!  :-)

There's nothing really special or limiting about CVS here either.  The
same kinds of rules must be followed for any kind of versioning tool
that manages multiple files "simultaneously".  It really just boils down
to fairly simple database theory.

-- 
Greg A. Woods

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


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

Re: Tag locking change

[Greg A. Woods]

[ On Wednesday, October 9, 2002 at 10:13:42 (-0700), Paul Sander wrote: ]
> Subject: Re: Tag locking change
>
> There are lots of cases where someone demands "tag branch x as of time y".

What the heck does that have to do with tagging the head of a branch?!?!?!?

> As for the instantaneous part:  It takes a while for CVS to apply tags
> using the rtag command.

Well, "Duh!"

>  The proposed change to the locking system opens
> a race condition between rtag and commit, where the head of the branch
> can change while the tag is being applied.

The point is you shouldn't be tagging the head of the branch without
doing so from within a working directory which is up-to-date to the head
of the branch in the first place.  It really doesn't matter whether "cvs
rtag" makes it a safe "atomic" operation or not.

> However, assuming a timestamp of "now" during rtag is a low-overhead and
> lock-free method to remove the race condition.

Well, yes, in the implementation "now" hopefully gets converted to the
time at the start of the command and doesn't change as the procedure
progresses, and so it's a silly cheap trick to still get undefined
results with the tag

-- 
Greg A. Woods

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


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

Re: Tag locking change

[Adam Bregenzer]

On Wed, 2002-10-09 at 14:58, Greg A. Woods wrote:
> [ On , October 9, 2002 at 14:26:15 (-0400), Adam Bregenzer wrote: ]
> > Subject: Re: Tag locking change
> >
> > On Wed, 2002-10-09 at 13:58, Greg A. Woods wrote:
> > > 
> > > Yes, sure, but that copying is done (or at least the source for the
> > > copying is created with) "cvs update", RIGHT?  (i.e. it had better be!)
> > 
> > Not at all.  The server that holds the cvs repository also has apache
> > runing on it.  When a commit occurs each file that is committed is
> > copied into a seperate directory.  That directory is the DocumentRoot
> > for apache.  That way, when a change is committed it is automagicall
> > viewable by browsing to the cvs server.  The point is that one who does
> > not edit the site manages and approves the site.
> 
> My point was that you can do the same thing more reliably with a "cvs
> update" in a working directory that is the DocumentRoot.
But then it wouldn't be automagic, it would be whenever cvs update is
run.  Certianly every minute would be 'acceptable' but this solution is
fine.  Plus in this case the repository and the live site have different
directory structures.

> 
> >  Currently that
> > individual runs cvs rtag when the site is in a producation ready state. 
> 
> Then that individual _could_ edit the site, so it is irrelevant from the
> access rights point of view whether or not that indivudual runs "cvs
> tag" or "cvs rtag".
He/she certianly *could* but do you want a manager knowing they can? :P
Plus, she doesn't modify the code so why keep or have a checked out
copy?  (I understand it's necessary in cvs, I'm trying to make a point)

> 
> > Then a script is run that does a cvs export with that tag and posts it
> > to the live site.  It has nothing to do with the client, it's all
> > *server* side.  I see no reason for it to bve tied to an update, I don't
> > even know how to execute a server-side script on update and wouldn't
> > want to anyways.
> 
> You could trigger the server-side "cvs update" in any number of ways,
> though the very best would be if the individual doing the testing and
> approving did it just before testing.
It's primarially for the developers, the testers only see it at
regularly scheduled intervals so a developer's commit doesn't fsck
something up.  The environment on the cvs server emulates the live
environment, most developer machines do not that is the reason for the
constant sync with cvs, immediate testing  Plus, I don't want to
give testers access to the test server and I don't want to write an
interface for them to do it.

> 
> > > When it's "ready" you should be "cvs tag"ing the working directory which
> > > matches the "ready" revisions of the files.
> > 
> > But what if I have not working directory.  What if the developers are
> > just that.  Developers.  I can certianly tell them to tag it for me but
> > that's a bit strange.
> 
> That does not make any sense.  You can have a working directory if you want.
Well, the first sentence should be 'But what if I don't have a working
directory', but I think you mean my point doesn't make sense.  What if
you don't want or need to have a working copy?  You cannot really do
anything in cvs without a working copy, which is obviously something
some people on this list have not realized.  The fact that what I said
doesn't make sense is a reflection upon you of the design and
methodology in cvs.  Ya know not everybody wants a working copy

> 
> > Actually, I realized something else, you can't run an rtag from a
> > application that was run from a commitinfo script.  That's what I was
> > thinking.
> 
> You can't run "cvs tag" directly from comitinfo scripts either, but that
> shouldn't be an issue.  It's easy enough to design better solutions.
> 
> 
> -- 
>   Greg A. Woods
> 
> +1 416 218-0098;<[EMAIL PROTECTED]>;   <[EMAIL PROTECTED]>
> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]>



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

Re: Tag locking change

[Greg A. Woods]

[ On , October 9, 2002 at 14:26:15 (-0400), Adam Bregenzer wrote: ]
> Subject: Re: Tag locking change
>
> On Wed, 2002-10-09 at 13:58, Greg A. Woods wrote:
> > 
> > Yes, sure, but that copying is done (or at least the source for the
> > copying is created with) "cvs update", RIGHT?  (i.e. it had better be!)
> 
> Not at all.  The server that holds the cvs repository also has apache
> runing on it.  When a commit occurs each file that is committed is
> copied into a seperate directory.  That directory is the DocumentRoot
> for apache.  That way, when a change is committed it is automagicall
> viewable by browsing to the cvs server.  The point is that one who does
> not edit the site manages and approves the site.

My point was that you can do the same thing more reliably with a "cvs
update" in a working directory that is the DocumentRoot.

>  Currently that
> individual runs cvs rtag when the site is in a producation ready state. 

Then that individual _could_ edit the site, so it is irrelevant from the
access rights point of view whether or not that indivudual runs "cvs
tag" or "cvs rtag".

> Then a script is run that does a cvs export with that tag and posts it
> to the live site.  It has nothing to do with the client, it's all
> *server* side.  I see no reason for it to bve tied to an update, I don't
> even know how to execute a server-side script on update and wouldn't
> want to anyways.

You could trigger the server-side "cvs update" in any number of ways,
though the very best would be if the individual doing the testing and
approving did it just before testing.

> > When it's "ready" you should be "cvs tag"ing the working directory which
> > matches the "ready" revisions of the files.
> 
> But what if I have not working directory.  What if the developers are
> just that.  Developers.  I can certianly tell them to tag it for me but
> that's a bit strange.

That does not make any sense.  You can have a working directory if you want.

> Actually, I realized something else, you can't run an rtag from a
> application that was run from a commitinfo script.  That's what I was
> thinking.

You can't run "cvs tag" directly from comitinfo scripts either, but that
shouldn't be an issue.  It's easy enough to design better solutions.


-- 
Greg A. Woods

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


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

Re: "cvs commit" features

[Mike Ayers]

Reinstein, Shlomo wrote:

> Of course, a user can always use "cvs add" and "cvs remove" to add or remove
> files, but these two options can help him/her make sure they didn't forget
> to do this for some of the files.

This is one of those things that might work really well, but only for 
certain development models.  For instance, I am using a GUI based 
tool.  It likes to create lots of files that may or may not need to be 
archived.  I have experimentally determined that if I archive a 
certain set of them, then there seems to be no problems.  Do I want 
CVS to pester me about the ones I'm not archiving every time I do a 
commit in that directory?  No way!

And just think what would happen if you inadvertently did your CVS 
commit without making clean first...

Nannyware sucks.

Optional nannying?  Hmmm - doesn't the nannyware model *require* that 
the nagging not be optional?


/|/|ike




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

Re: Tag locking change

[Paul Sander]

>--- Forwarded mail from [EMAIL PROTECTED]

>[ On Tuesday, October 8, 2002 at 22:32:18 (-0700), Mike Ayers wrote: ]
>> Subject: Re: Tag locking change
>>
>> Greg A. Woods wrote:
>> 
>> > If you really Really REALLY want to tag the head of a branch then just
>> > check out the branch (or do a "cvs update" in any existing working
>> > directory which has no un-committed changes) then then apply the tag to
>> > what you get as a result by running "cvs tag" in that working directory.
>> > That way you can know ahead of time exactly what you've got.  It's then
>> > up to the user whether or not they actually look to see what's there
>> > before they tag it.
>> 
>>  What I fail to understand is why anyone would want to tag the head of 
>> a branch in an instantaneous fashion.

>Me too!  :-)

There are lots of cases where someone demands "tag branch x as of time y".
It's used often enough when someone doesn't care what the specific version
numbers are, or they don't know or care what tags (if any) have been
applied to those versions.  But they know what features they want, and
they know when those features were committed to the branch, so the
branch/timestamp pair is their means of identifying specific configurations.
In some shops that apply tags infrequently, this may indeed be the only
means to identify a configuration.

I claim that "y" == "now" is a common special case.  Therein lies the
"tag the head of a branch" issue.

As for the instantaneous part:  It takes a while for CVS to apply tags
using the rtag command.  The proposed change to the locking system opens
a race condition between rtag and commit, where the head of the branch
can change while the tag is being applied.  Some of us think this is
bad and would consider it a bug, while others seem to think this is bad and
would consider it a feature.

However, assuming a timestamp of "now" during rtag is a low-overhead and
lock-free method to remove the race condition.  The same trick could be
used for checkout or update to improve throughput even when concurrent
commits are made to the same branch, provided commits continue to use
two-phase locking principles.

>--- End of forwarded message from [EMAIL PROTECTED]



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

Re: Tag locking change

[Adam Bregenzer]

On Wed, 2002-10-09 at 13:58, Greg A. Woods wrote:
> [ On , October 9, 2002 at 10:03:08 (-0400), Adam Bregenzer wrote: ]
> > Subject: Re: Tag locking change
> >
> > I can think of specific examples where testing, etc. may not happen in a
> > 'working copy' of the code.  For example, one of the projects I am using
> > cvs for is a website.  I have a script in cvs that, upon checkin, copies
> > the file over to a directory so that the 'current' cvs version of the
> > site can be immediately tested.
> 
> Yes, sure, but that copying is done (or at least the source for the
> copying is created with) "cvs update", RIGHT?  (i.e. it had better be!)

Not at all.  The server that holds the cvs repository also has apache
runing on it.  When a commit occurs each file that is committed is
copied into a seperate directory.  That directory is the DocumentRoot
for apache.  That way, when a change is committed it is automagicall
viewable by browsing to the cvs server.  The point is that one who does
not edit the site manages and approves the site.  Currently that
individual runs cvs rtag when the site is in a producation ready state. 
Then a script is run that does a cvs export with that tag and posts it
to the live site.  It has nothing to do with the client, it's all
*server* side.  I see no reason for it to bve tied to an update, I don't
even know how to execute a server-side script on update and wouldn't
want to anyways.

> 
> >  There is not branching in the code or
> > anything fancy so I currently use rtag to tag the head of the branch
> > when we decide it is ready.
> 
> When it's "ready" you should be "cvs tag"ing the working directory which
> matches the "ready" revisions of the files.
But what if I have not working directory.  What if the developers are
just that.  Developers.  I can certianly tell them to tag it for me but
that's a bit strange.

> 
> What do you do with that tag afterwards?  Presumably you "cvs export"
> using it and create a master copy of the "ready" files to ship to your
> production web servers?  That would be the right way to do the release.
> 

Of course I do, it's how that tag is generated that we are discussing.

> > Also, it can be convienent to use
> > rtag if cvs is integrated with other tools.
> 
> You mean to tag the head of a branch?  That doesn't make sense.  What's
> more "convenient" about getting undefined results!?!?!?!

Actually, I realized something else, you can't run an rtag from a
application that was run from a commit info script.  That's what I was
thinking.  This is a bad example from a practiaclity standpoint but it
does illistrate my point.  Say every time you commit changes, a script
runs, looks at the first line of your comment and checks for a bug
number.  If it finds one it tags the entire source tree and adds a
comment to your bug tracking software with the tag.  This can't be
easily or practically done with a working copy of the code.  While there
are several better ways to do it and you probably can't run an rtag
command from a script run from a *info file it is an example.

Really, with the way cvs is written, I agree that rtag should lock on a
per-directory basis.  However, it can be frustrating that cvs suffers
from such a narrow scope.

> 
> -- 
>   Greg A. Woods
> 
> +1 416 218-0098;<[EMAIL PROTECTED]>;   <[EMAIL PROTECTED]>
> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]>
> 
> 
> ___
> 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: report on building CVS 1.11.2 on NT

[Larry Jones]

Kris Thielemans writes:
> 
> D:\kris\temp>cvs-1.11.2\Windebug\cvs -d parapet:/usr/local/cvsroot -t
> checkout parapet
> -> main loop with CVSROOT=parapet:/usr/local/cvsroot
>  -> Starting server: rsh parapet cvs server
> ' from cvs serverning: unrecognized response `ok

Your rsh client is doing end-of-line conversions which screws up the CVS
client/server protocol.  Just use the built-in :server: method instead
of the (default) :ext: method and it should work fine.

-Larry Jones

All this was funny until she did the same thing to me. -- Calvin


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

Re: Tag locking change

[Greg A. Woods]

[ On Wednesday, October 9, 2002 at 11:26:08 (-0400), Larry Jones wrote: ]
> Subject: Re: Tag locking change
>
> Greg A. Woods writes:
> > 
> > I think the issue is some of us don't want 'cvs rtag' to "work" when the
> > intent is to tag the head of a branch, especially not with the new more
> > per-directory-only locking scheme
> 
> Just to reemphasize, the per-directory locking scheme is not "new", it's
> what all versions of CVS prior to 1.11.1 used.  The change to locking
> the entire tree in CVS 1.11.1 was a stop-gap fix for a serious bug that
> could cause data loss.

Yes, of course.  Sorry about that -- I didn't mean to confuse 1.11.1
with older versions!  :-)

-- 
Greg A. Woods

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


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

Re: Tag locking change

[Greg A. Woods]

[ On , October 9, 2002 at 10:03:08 (-0400), Adam Bregenzer wrote: ]
> Subject: Re: Tag locking change
>
> I can think of specific examples where testing, etc. may not happen in a
> 'working copy' of the code.  For example, one of the projects I am using
> cvs for is a website.  I have a script in cvs that, upon checkin, copies
> the file over to a directory so that the 'current' cvs version of the
> site can be immediately tested.

Yes, sure, but that copying is done (or at least the source for the
copying is created with) "cvs update", RIGHT?  (i.e. it had better be!)

>  There is not branching in the code or
> anything fancy so I currently use rtag to tag the head of the branch
> when we decide it is ready.

When it's "ready" you should be "cvs tag"ing the working directory which
matches the "ready" revisions of the files.

What do you do with that tag afterwards?  Presumably you "cvs export"
using it and create a master copy of the "ready" files to ship to your
production web servers?  That would be the right way to do the release.

> Also, it can be convienent to use
> rtag if cvs is integrated with other tools.

You mean to tag the head of a branch?  That doesn't make sense.  What's
more "convenient" about getting undefined results!?!?!?!

-- 
Greg A. Woods

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


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

Re: Add proxy support to cvs?

[Greg A. Woods]

[ On Wednesday, October 9, 2002 at 09:17:37 (+0200), Fabian Cenedese wrote: ]
> Subject: Add proxy support to cvs?
>
> At the moment I'm using WinCvs because it's the only way to get over
> our company proxy. It's not possible with native cvs. But I'd like to work
> with normal cvs so I can also use it on the Linux box. The guys from
> WinCvs added proxy support so it's not impossible. Wouldn't that be
> something for cvs also? There have been quite some questions/requests
> on this list about this subject. If WinCvs could use cvs, why not in return
> use something from WinCvs?

Since you should be using SSH to connect to your CVS server all this
proxy business should be invisible to CVS and done by SSH.

-- 
Greg A. Woods

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


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

Re: "cvs commit" features

[Greg A. Woods]

[ On Wednesday, October 9, 2002 at 07:41:59 (+0200), Reinstein, Shlomo wrote: ]
> Subject: "cvs commit" features
>
> 1. An option to make "commit" ask you if you'd like to get rid of files that
> exist in the repository but not in your working directory, and possibly
> specify on the command-line which files to remove (or have the "commit" ask
> you for each file or for each file extension).

If you're already writing wrapper scripts then one to do that is nearly
trivial to write using 'cvs -nq update'.

> 2. An option to make "commit" ask you if you'd like to add files that exist
> in your working directory but not in the repository, and possibly specify on
> the command-line which files to add  (or have the "commit" ask you for each
> file or for each file extension).

Once again that's an almost trivial wrapper script to write.

> Of course, a user can always use "cvs add" and "cvs remove" to add or remove
> files,

Indeed one can and one should.

> but these two options can help him/her make sure they didn't forget
> to do this for some of the files.

No, not really.  Think of the CVS sub-commands as verbs for your wrapper
scripts and use them that way.  You don't want complex verbs that
confuse the meaning of what's really going on.

-- 
Greg A. Woods

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


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

RE: report on building CVS 1.11.2 on NT

[Kris Thielemans]

Ok,
I tried that and it does compile+link now (using VC 6.0).

Unfortunately, it doesn't seem to work:

D:\kris\temp>cvs-1.11.2\Windebug\cvs -d parapet:/usr/local/cvsroot -t
checkout parapet
-> main loop with CVSROOT=parapet:/usr/local/cvsroot
 -> Starting server: rsh parapet cvs server
' from cvs serverning: unrecognized response `ok

is what I get using this compiled cvs version...

Oh well, the README does mention you should check which versions is supposed
to work on NT.


Thanks for the help!

Kris

> Or just download the real one from:
>
>   
>
> It was accidentally omitted from the source distribution.
>
> -Larry Jones



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

Re: report on building CVS 1.11.2 on NT

[Larry Jones]

Mike Pumford writes:
> 
> Create a windows-NT/getpagesize.h containing:
> 
> #define getpagesize() 4096
> 
> IIRC this will get things to build. 

Or just download the real one from:



It was accidentally omitted from the source distribution.

-Larry Jones

I always send Grandma a thank-you note right away.  ...Ever since she
sent me that empty box with the sarcastic note saying she was just
checking to see if the Postal Service was still working. -- Calvin


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

Re: Tag locking change

[Larry Jones]

Greg A. Woods writes:
> 
> I think the issue is some of us don't want 'cvs rtag' to "work" when the
> intent is to tag the head of a branch, especially not with the new more
> per-directory-only locking scheme

Just to reemphasize, the per-directory locking scheme is not "new", it's
what all versions of CVS prior to 1.11.1 used.  The change to locking
the entire tree in CVS 1.11.1 was a stop-gap fix for a serious bug that
could cause data loss.

-Larry Jones

I'm crying because out there he's gone, but he's not gone inside me. -- Calvin


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

Re: report on building CVS 1.11.2 on NT

[Mike Pumford]

> Hi,
> 
> just to let you know:
> 
> I've successfully built CVS 1.11.2 on my NT 4.0 sp6a machine  using the
> cygwin tools (which includes gcc 2.95.2). Just following the Unix
> installation description worked fine. This CVS version also seems to run
> fine on my NT machine.
> 
> 
> 
> I've also tried to use VC 6.0, but get stuck there during compilation:
> nmake /f cvsnt.mak CFG="cvsnt - Win32 Debug"
> 
> .\lib\valloc.c(10) : fatal error C1083: Cannot open include file:
> 'getpagesize.h':
> No such file or directory
> 
> Indeed, that file contains lines
> #ifndef HAVE_GETPAGESIZE
> # include "getpagesize.h"
> #endif
> 
Create a windows-NT/getpagesize.h containing:

#define getpagesize() 4096

IIRC this will get things to build. 

Mike





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

Re: Tag locking change

[Adam Bregenzer]

I can think of specific examples where testing, etc. may not happen in a
'working copy' of the code.  For example, one of the projects I am using
cvs for is a website.  I have a script in cvs that, upon checkin, copies
the file over to a directory so that the 'current' cvs version of the
site can be immediately tested.  There is not branching in the code or
anything fancy so I currently use rtag to tag the head of the branch
when we decide it is ready.  While this is a very limited case and there
are few enough developers that I can still run rtag and tell everybody
to not checkin anything for a minute.  Also, it can be convienent to use
rtag if cvs is integrated with other tools.  One thing I think this
shows is that cvs is a tool for developers, by developers, which may not
work in every instance.


On Wed, 2002-10-09 at 02:15, Greg A. Woods wrote:
> [ On Tuesday, October 8, 2002 at 22:32:18 (-0700), Mike Ayers wrote: ]
> > Subject: Re: Tag locking change
> >
> > Greg A. Woods wrote:
> > 
> > > If you really Really REALLY want to tag the head of a branch then just
> > > check out the branch (or do a "cvs update" in any existing working
> > > directory which has no un-committed changes) then then apply the tag to
> > > what you get as a result by running "cvs tag" in that working directory.
> > > That way you can know ahead of time exactly what you've got.  It's then
> > > up to the user whether or not they actually look to see what's there
> > > before they tag it.
> > 
> > What I fail to understand is why anyone would want to tag the head of 
> > a branch in an instantaneous fashion.
> 
> Me too!  :-)
> 
> >  Wouldn't you want to 
> > build/test, etc. first?
> 
> Well, in theory you could check out a working directory with the new tag
> and test it then, and you could adjust the tagged revision in any files
> where some unexpected change had in fact crept in.
> 
> It does seem like the wrong way to go about things though especially
> when you can just update a working directory and then be certain that
> what you tag is correct in the first place.
> 
> > I'm kind of lost on what the point of contention is here.  What is it 
> > that someone would want to do that is affected by the tag locking 
> > change?  Could someone please clarify?
> 
> I think the issue is some of us don't want 'cvs rtag' to "work" when the
> intent is to tag the head of a branch, especially not with the new more
> per-directory-only locking scheme it will use to work faster and to
> cause less contention (i.e. it should give a usage error).  Other people
> seem to think that indeed it should be possible to tag the head of a
> branch with 'cvs rtag'.
> 
> Indeed silly tricks could still be done with the likes of specifying a
> time only one second prior to the current time.  Of course the very idea
> of using timestamps is open to question as well since unless you have
> some external way to ensure the repository is quiescent for a decent
> window of time you still can't know what you're tagging.
> 
> CVS just gives users far too much rope for many tasks.
> 
> -- 
>   Greg A. Woods
> 
> +1 416 218-0098;<[EMAIL PROTECTED]>;   <[EMAIL PROTECTED]>
> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]>
> 
> 
> ___
> 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: Add proxy support to cvs?

[Jenn Vesperman]

On Wed, 2002-10-09 at 17:17, Fabian Cenedese wrote:
> Hi
> 
> At the moment I'm using WinCvs because it's the only way to get over
> our company proxy. It's not possible with native cvs. But I'd like to work
> with normal cvs so I can also use it on the Linux box. The guys from
> WinCvs added proxy support so it's not impossible. Wouldn't that be
> something for cvs also? There have been quite some questions/requests
> on this list about this subject. If WinCvs could use cvs, why not in return
> use something from WinCvs?

If you can use ssh to get through your company proxy, you can set the
CVS_RSH environment variable to ssh (or ssh2), and use the :ext: method
to access the server.

If you need to use ssh with options or parameters, you can even set
CVS_RSH to a shell script that calls ssh with those parameters.


What form of proxy is it? What type(s) of proxy(s) is(are) WinCVS
supporting? There're a lot out there, without more information it's
impossible to actually say 'oh, you can use blah'.





Jenn V.
-- 
"Do you ever wonder if there's a whole section of geek culture 
you miss out on by being a geek?" - Dancer.

[EMAIL PROTECTED] http://anthill.echidna.id.au/~jenn/




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

report on building CVS 1.11.2 on NT

[Kris Thielemans]

Hi,

just to let you know:

I've successfully built CVS 1.11.2 on my NT 4.0 sp6a machine  using the
cygwin tools (which includes gcc 2.95.2). Just following the Unix
installation description worked fine. This CVS version also seems to run
fine on my NT machine.



I've also tried to use VC 6.0, but get stuck there during compilation:
nmake /f cvsnt.mak CFG="cvsnt - Win32 Debug"

.\lib\valloc.c(10) : fatal error C1083: Cannot open include file:
'getpagesize.h':
No such file or directory

Indeed, that file contains lines
#ifndef HAVE_GETPAGESIZE
# include "getpagesize.h"
#endif

I can compile that file by defining HAVE_GETPAGESIZE (changing the line in
windows-NT/config.h), but then of course I get a linking error

valloc.obj : error LNK2001: unresolved external symbol _getpagesize
.\WinDebug/cvs.exe : fatal error LNK1120: 1 unresolved externals


As I have the cygwin version, I'm not too worried about this, but for those
who wan tto investigate this further, it looks like there are 2 files
missing getpagesize.h and getpagesize.c.


Kris Thielemans
(kris.thielemans  ic.ac.uk)
Imaging Research Solutions Ltd
Cyclotron Building
Hammersmith Hospital
Du Cane Road
London W12 ONN, United Kingdom

web site address: http://www.irsl.org/~kris



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

Re: Read only file

[dd hh]

Thanks everybody :-) ...now things seem much more clearer and understandable.
Regards,
Anamika :-)
 Jenn Vesperman <[EMAIL PROTECTED]>wrote:
On Wed, 2002-10-09 at 02:03, dd hh wrote:> > Hi everyone, > Thanks a lot for the help :-) . But I am not able to understand why read only directory is required in CVS. Why can't we have directories which has both read and write permission and in that directories files with read only permission and some writable files too? Coz in normal unix this works perfectly fine. Could anyone explain it ? It's an artifact of the way CVS writes the RCS files (the files in therepository), and it's part of CVS attempting to make the writing anatomic operation.Rather than editing the actual RCS file, CVS copies the file to abackup, writes the changes to that, then renames the backup to theoriginal file. This means that it doesn't need write access to the RCS file, only tothe directory it's in.This ALSO means that read/write permissions in the repository can bemodified on a directory-by-directory level, not a file-by-file level.I hope this clarifies things for you.Jenn V.-- "Do you ever wonder if there's a whole section of geek culture you miss out on by being a geek?" - Dancer.[EMAIL PROTECTED] http://anthill.echidna.id.au/~jenn/Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!