Hi,

A while ago, someone asked if it was possible, after rebuilding the
database from a cvs repository, to reorder all the transactions in
database such that they're in date order. I provided a sketch of the
general proceedure but never fleshed it out.

I've just needed to do it myself and have worked out the necessary sql.
Being MySQL, it's harder than it should be and you have to use temp
tables, but it's still possible. This won't make any attempt to inspect
bugzilla tables and I only really suggest you try this after an initial
database build when setting up either Tony's extensions of cvszilla or
cvszillaJ. The SQL is:

create temporary table foo
     as select username, joblist, log_message, mtime, ctime
        from transactions
        order by mtime, ctime;

alter table foo add column id int auto_increment primary key first;

create temporary table foo_entry
     as select foo.id, oldversion, newversion, filepath, branch
        from
          foo
            inner join
          transactions
            using (username, joblist, log_message, mtime, ctime)
            inner join
          transaction_entry
            on transaction = transactions.id;

delete from transaction_entry;

delete from transactions;

insert into transaction_entry select * from foo_entry;

insert into transactions select * from foo;

drop table foo;

drop table foo_entry;

Matthew
--
Matthew Sackman

BOFH excuse #316:
Elves on strike. (Why do they call EMAG Elf Magic)

On Tue, 2005-12-06 at 17:03 +0000, matthew@... wrote:
> In terms of added features and general level of maintanence it's
> probably a better bet than cvszilla (without trying to take anything
> away from the cvszilla authors) largely because I get paid to fix it and
> add features to it...
>
> Hopefully, before christmas, my java version should migrate over onto
> the cvszilla.org site. Hopefully.

Getting paid for it is definitely going to result in better
maintenance.

[begin oblig slashdot reference - groaning allowed]
I for one welcome our new Java overlords.
[end]

However, as I said earlier, if you would like to submit patches, please
let me know, I'm willing to open up commit access.  I'm able to review
fixes, just not actually find the time to do them myself.

Jason

On Tue, Dec 06, 2005 at 07:03:36AM -0000, Miro wrote:
> When trying to checkin file to CVS containing spaces, it fails due to
> bug in cvszilla script :
> logmsg.archive, since it's do expect  file name without spaces
> dose any one know if there is a fix for that ?

Which version of cvs are you using? If it's pre 1.12.6 then you must
format the entries in your loginfo file using lots of commas. If it's
after 1.12.5 then cvs invokes the scripts properly, manually filling the
argv correctly so the crazy commas aren't needed. Whether that means
that it breaks cvszilla or not I'm afraid I don't know - I would have
hoped that if you turn off comma_parsing in the config and strip the
commas from the loginfo then it should work with spaces in post 1.12.5
cvs. I don't think I've tested that though.

What I do know is that it definitely will work with cvszillaJ which is a
java rewrite of parts of cvszilla. cvszillaJ will sometime in the future
merge with cvszilla. Quite how and when that will happen I don't know.
In the mean time, head to http://www.wellquite.org/cvszillaj/

In terms of added features and general level of maintanence it's
probably a better bet than cvszilla (without trying to take anything
away from the cvszilla authors) largely because I get paid to fix it and
add features to it...

Hopefully, before christmas, my java version should migrate over onto
the cvszilla.org site. Hopefully.

Matthew
--
Matthew Sackman

BOFH excuse #435:
Internet shut down due to maintenance

When trying to checkin file to CVS containing spaces, it fails due to
bug in cvszilla script :
logmsg.archive, since it's do expect  file name without spaces
dose any one know if there is a fix for that ?

On Wed, Nov 30, 2005 at 04:11:42PM +0000, matthew@... wrote:
> If you can wait until the weekend then I'll get a new version of
> cvszillaj up - I've made a whole bunch of improvements to the web code
> over the last couple of months and I've also converted all the java code
> to use generics so it's in a bit of a better state too.

Right, it's now up. Head to http://www.wellquite.org/cvszillaj/ for the
newest version (0.2.3). Nearly all the improvements are on the web site
of things which is all still in Perl. The main focus of the improvements
is in dealing with branches. Please let me know if you run into any
problems.

Matthew
--
Matthew Sackman

BOFH excuse #21:
POSIX compliance problem

On Thu, Dec 01, 2005 at 09:27:16AM +1300, Bruce Hoult wrote:
> Anyone using cvszilla with Bugzilla 2.20?  Any issues?

Yes. It works fine with the Java version, I can't speak for the purely
Perl version though, though I'd be surprised if there were problems.
Most of the schema changes for 2.20 are away from the main bugs table so
cvszilla should be safe.

Matthew
--
Matthew Sackman

BOFH excuse #250:
Program load too heavy for processor to lift.

I've found the issue, thank you for your help.

I've inherited a variety of systems from a previous admin. It seems that
while a VC db was there (and empty) the bugs db had the vc tables just
added on to it.

So the old version of cvszilla was pointing to this bug db for the vc
tables, where as I was quite clueless.

I added the new table, bug_to_cvs_user, and it works perfectly. Thank
you for your help.

> -----Original Message-----
> From: cvszilla@yahoogroups.com [mailto:cvszilla@yahoogroups.com] On
Behalf
> Of Jason Pollock
> Sent: Wednesday, November 30, 2005 1:40 PM
> To: cvszilla@yahoogroups.com
> Subject: Re: [cvszilla] Issues with transactions not being in order
> usingnew cvszilla code.
>
> On Wed, 2005-11-30 at 15:13 +0000, que wrote:
> > Using the old version I have for cvszilla, transactions are updated
in
> > order.
> >
> > I've upgraded to the newest version which uses cvsdb modules
instead,
> > and the transactions have started over at 1.
>
> That's odd that it's restarted at 1.
>
> >
> > I've read a couple entries on the list about this issue, but I have
a
> > question.
> >
> > In the previous version when I move it to a new server it picks up
the
> > transaction id just fine. In the new version it has to reread the
tree?
>
> That's very odd that it is restarting from 1.  The perl version of
> cvszilla relies on mysql to maintain the numbering, through the
> auto-increment ID column.
>
> To change the auto-increment next value, try the following:
>
> ALTER TABLE transactions AUTO_INCREMENT = xxxx
>
> where xxxx is the current maximum transaction id + 1...
>
> SELECT MAX(id)+1 from transactions
>
> Jason
>
>
>
> ------------------------ Yahoo! Groups Sponsor
>
>
> Yahoo! Groups Links
>
>
>
>
>
>

On Thu, 2005-12-01 at 09:27 +1300, Bruce Hoult wrote:
> Hi,
>
> Anyone using cvszilla with Bugzilla 2.20?  Any issues?
>
> I haven't used cvszilla in nearly a year but now want to do an
> install for a client.  I have an existing  bz account on the site,
> but if I have a cvs account then I've lost/forgotten the details.
> <tvad>Jay-son!!</tvad> ;-)  I see the web page doesn't mention that
> it works with svn, which could perhaps do with being updated.
>
> Bruce

Yeah, I've been slack.  Well busy actually.  Planning a wedding, buying
a house, trips, relatives with kids.  Busy year.

You do have a cvs account.  If you send me an htpasswd file, I'll update
the password for you.

As a note to everyone else.  If you would like to have CVS commit
access, drop me a line.

Jason

On Wed, 2005-11-30 at 15:13 +0000, que wrote:
> Using the old version I have for cvszilla, transactions are updated in
> order.
>
> I've upgraded to the newest version which uses cvsdb modules instead,
> and the transactions have started over at 1.

That's odd that it's restarted at 1.

>
> I've read a couple entries on the list about this issue, but I have a
> question.
>
> In the previous version when I move it to a new server it picks up the
> transaction id just fine. In the new version it has to reread the tree?

That's very odd that it is restarting from 1.  The perl version of
cvszilla relies on mysql to maintain the numbering, through the
auto-increment ID column.

To change the auto-increment next value, try the following:

ALTER TABLE transactions AUTO_INCREMENT = xxxx

where xxxx is the current maximum transaction id + 1...

SELECT MAX(id)+1 from transactions

Jason

Hi,

Anyone using cvszilla with Bugzilla 2.20?  Any issues?

I haven't used cvszilla in nearly a year but now want to do an
install for a client.  I have an existing  bz account on the site,
but if I have a cvs account then I've lost/forgotten the details.
<tvad>Jay-son!!</tvad> ;-)  I see the web page doesn't mention that
it works with svn, which could perhaps do with being updated.

Bruce

On Wed, Nov 30, 2005 at 08:45:05AM -0700, Nathan Oyler wrote:
> Also, the copy of the Java db generator isn't saved from the attachment
> before, can someone send that or the perl version to me?
>
> It's an option, I'd like to take a look at if I can get a copy.

For the Java version, please see http://www.wellquite.org/cvszillaj/

If you can wait until the weekend then I'll get a new version of
cvszillaj up - I've made a whole bunch of improvements to the web code
over the last couple of months and I've also converted all the java code
to use generics so it's in a bit of a better state too.

Matthew
--
Matthew Sackman

BOFH excuse #154:
You can tune a file system, but you can't tune a fish (from most tunefs man
pages)

Also, the copy of the Java db generator isn't saved from the attachment
before, can someone send that or the perl version to me?

It's an option, I'd like to take a look at if I can get a copy.

> -----Original Message-----
> From: cvszilla@yahoogroups.com [mailto:cvszilla@yahoogroups.com] On
Behalf
> Of que
> Sent: Wednesday, November 30, 2005 8:14 AM
> To: cvszilla@yahoogroups.com
> Subject: [cvszilla] Issues with transactions not being in order using
new
> cvszilla code.
>
> Using the old version I have for cvszilla, transactions are updated in
> order.
>
> I've upgraded to the newest version which uses cvsdb modules instead,
> and the transactions have started over at 1.
>
> I've read a couple entries on the list about this issue, but I have a
> question.
>
> In the previous version when I move it to a new server it picks up the
> transaction id just fine. In the new version it has to reread the
tree?
>
> Is there anyway to just change the transactions to work the old way
> easily? I know enough perl to script myself out of a paper bag, and
> feel like I could start working on this but I don't want to get
> somewhere only to realize it isn't going to work.
>
> All I want is transaction numbers to continue on their path for each
> commit. Thanks.
>
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor
>
>
> Yahoo! Groups Links
>
>
>
>
>

Using the old version I have for cvszilla, transactions are updated in
order.

I've upgraded to the newest version which uses cvsdb modules instead,
and the transactions have started over at 1.

I've read a couple entries on the list about this issue, but I have a
question.

In the previous version when I move it to a new server it picks up the
transaction id just fine. In the new version it has to reread the tree?

Is there anyway to just change the transactions to work the old way
easily? I know enough perl to script myself out of a paper bag, and
feel like I could start working on this but I don't want to get
somewhere only to realize it isn't going to work.

All I want is transaction numbers to continue on their path for each
commit. Thanks.

Hi Steeve,

Bernier, Steeve (EXP) wrote:
> It is possible to install CVSZilla on a Windows platform, if yes where I
> can find the documentation.

I've never tried it! In principle I don't see a problem with it; you'd
need to be using perl and pserver- or ssh-based CVS server mode. It
might be easiest to install the full cygwin toolchain on your CVS server
machine. The instructions for installing cvszilla should be very similar
to using CVS in network-service mode on Unix - give it a try and let us
know how you get on.

Regards,
   Tony

Hrm.

I can't tell immediately what is wrong.

Let's try a couple of things.

I take it you installed cvszilla in /usr/local/cvszilla?

Did querytag.cgi get installed there?
Is querytag.cgi executable by the account running the web server?
To check your apache config, can you access the normal query page,
"query.cgi"?

There may be other problems, but we can start with that. :)

Regards,
Jason

On Wed, 2005-09-21 at 02:54, Miro wrote:
> I just installed cvszilla on linux, evry thing is working fine except
> the "query tags" page, when I press the link I get "Internal Server
> Error" , and in the apache error log I get :
> (2)No such file or directory: exec of '/usr/local/cvszilla/cgi-
> bin/querytag.cgi' failed, referer: http://devenv/cvszilla/query.cgi
>
> any idea ?
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>

I just installed cvszilla on linux, evry thing is working fine except
the "query tags" page, when I press the link I get "Internal Server
Error" , and in the apache error log I get :
(2)No such file or directory: exec of '/usr/local/cvszilla/cgi-
bin/querytag.cgi' failed, referer: http://devenv/cvszilla/query.cgi

any idea ?

Hi Leonid,

What should I do?

BTW, xxZilla seams to interpret names with blanks incorrectly. For example,
"EFP Performance Data.xls", "multicast DD.doc", etc.

Thanks,

Igor

Control this transaction

Transaction ID

Details

Submitting CVS user:	igort
Created:	2005-09-05 05:18:51
Closed:	2005-09-05 05:18:51
Jobs this transaction relates to:	bug 36

Log Message

efp: documents

Files

Filename	Old version	New version (Diffs)	Branch
Directory: /efp/quicc/ucode/doc
1.1	quadroDD.doc	NONE	(trunk)
DD.doc	NONE	1.1	(trunk)
EFP	Performance	Data.xls (diffs)	(trunk)
NONE	1.1	EFP_porting.txt (diffs)	(trunk)
NONE	1.1	LPM (diffs)	(trunk)
multicast	DD.doc	NONE	(trunk)

Thanks,

Leonid

Yes, "editcvs" is rather sneaky. :)

The editcvs group is a bugzilla group.  To avoid creating our own user
and permission management system, we're piggy backing on theirs.  When
you log into Bugzilla, if you have admin permissions, you will see

"Edit: Prefs | Parameters | Users | Products | Flags | Groups | Keywords"

in the footer of the search page (and probably others).  Click on
"Groups", create a group called "editcvs" and assign the relevant people
to it.

Hope this helps,
Jason

On Fri, 2005-09-02 at 15:08, Steven W. Orr wrote:
> Last time I asked a question here I was very successful. I now have
> cvszilla deployed and somehow I managed to fool them all into thinking it
> works :-)
>
> I have a question about functionality that seems to be there that I can't
> seem to access.
>
> If I go to
> http://penguin/cvszilla/usermapping.cgi
> I see a header that says
>
> CVS User Bug User
>
> but there's nothing under it.
>
> If I go to http://penguin/cvszilla/joblist.cgi
> I see a header that says
>
> Edit job... Description Active
> but there's nothing under it.
>
> And I get the message from editjob.cgi
> that I'm not a member of the editcvs group. And so, you aren't allowed to
> edit the parameters.
>
> Do I need to create an editcvs group? What's supposed to happen?
>
>
>
> Also, last time I posted, people asked to see my branch locking script. I
> put it up but no one actually looked at it. :-)
>
> I put it up here:
>
> http://steveo.syslang.net/lockBranch
>
> The invocation in the commitfile is
>
> ALL     /path/to/lockBranch repname $USER
>
> (We have multiple repositories here so we need to pass in the repname to
> decide on what to do.)

Last time I asked a question here I was very successful. I now have
cvszilla deployed and somehow I managed to fool them all into thinking it
works :-)

I have a question about functionality that seems to be there that I can't
seem to access.

If I go to
http://penguin/cvszilla/usermapping.cgi
I see a header that says

CVS User Bug User

but there's nothing under it.

If I go to http://penguin/cvszilla/joblist.cgi
I see a header that says

Edit job... Description Active
but there's nothing under it.

And I get the message from editjob.cgi
that I'm not a member of the editcvs group. And so, you aren't allowed to
edit the parameters.

Do I need to create an editcvs group? What's supposed to happen?



Also, last time I posted, people asked to see my branch locking script. I
put it up but no one actually looked at it. :-)

I put it up here:

http://steveo.syslang.net/lockBranch

The invocation in the commitfile is

ALL     /path/to/lockBranch repname $USER

(We have multiple repositories here so we need to pass in the repname to
decide on what to do.)

--
Time flies like the wind. Fruit flies like a banana. Stranger things have  .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net

On Thu, Aug 18, 2005 at 07:10:15AM -0000, hzzrzz wrote:
> After a couple of hiccups, the database rebuild was successful.
> However the regenerated transactions are not in chronological order.
> Is there a way to fix this?

Cool - you got it to work!

Um, no, there is no way currently to fix that. What happens is that the
program just parses every single RCS file that it finds and builds
transactions from scanning them. For it to be able to build them in
order, it would have to read every single RCS file, build internally all
the transactions and the flush out to the database which quickly
exhausts memory, unless you have a small CVS repository and a large
amount of RAM.

You could fix the database after the rebuild has taken place. The idea
here would be to insert into a new table from the old table, selecting
all columns but the transaction id and using a new sequence column for
the transaction id... something along the lines of

insert into new_transactions ($all cols but txid$)
select $all cols but txid$ from transactions order by $timestampCol$

You would then need to patch up the transaction_entry table with
something like:

update transaction_entry set transaction = new_transactions.id
from new_transactions, transactions
where new_transactions.$timestamp$ = transactions.$timestamp$
   and transaction_entry.transaction = transactions.id

then you'd finally need to rename the new_transaction table. Mmm, the
$timestampCol$ stuff would need to be worked carefully because you have
a start and an end timestamp which the above would rely on the
combination of which being unique.

Also, whether mysql is up to the task of the above I don't know.

I hope that's of some help!

Matthew
--
Matthew Sackman

BOFH excuse #355:
Boredom in the Kernel.

Mathew, I tried the the 0.2.2 version.

After a couple of hiccups, the database rebuild was successful.
However the regenerated transactions are not in chronological order.
Is there a way to fix this?

Thanks

--- In cvszilla@yahoogroups.com, Matthew Sackman <matthew@w...> wrote:
> On Thu, Jul 07, 2005 at 07:43:02PM -0000, matthewsackman wrote:
> > --- In cvszilla@yahoogroups.com, Tony Garnock-Jones <tonyg@k...>
> > wrote:
> > > hzzrzz wrote:
> > > > Where can I download the Matthew's Java version and your local
> > > > perl-cvszilla version of the DB rebuild scripts?
> > >
> > > I'm not sure Matthew has made his Java version publicly available
> > > yet, but I'll CC him on this. Matthew?
> >
> > I've sent it a couple of times to Jason but he's been really busy.
> > With any luck I'll have some time this weekend to tidy it up and
> > generally make it presentable. I'll chuck it on my website then.
>
> Right, I know it's not the weekend but...
>
> It's now up on http://www.wellquite.org/cvszillaj/
> Please give me a shout it it works for you or if it doesn't. It's very
> possible that the documentation is incomplete/unclear so let me know as
> and when you have problems. As I say on the page, you need to set up the
> config in two places and you need to edit the scripts in scripts/
>
> As Tony mentioned, you need a 1.5 JVM (otherwise known as Java 5).
>
> Matthew
> --
> Matthew Sackman
>
> BOFH excuse #292:
> We ran out of dial tone and we're and waiting for the phone company
to deliver another bottle.

On Thursday, Aug 11th 2005 at 13:32 +1200, quoth Jason Pollock:

=>On Thu, 2005-08-11 at 13:09, Steven W. Orr wrote:
=>> On Thursday, Aug 11th 2005 at 13:06 +1200, quoth Bruce Hoult:
=>>
=>> =>On 11/08/2005, at 12:58 PM, Steven W. Orr wrote:
=>> =>
=>> =>> Not quite there yet. I need just a *little* bit more before we get
=>> =>> clear
=>> =>> as mud ;-)
=>> =>>
=>> =>> What is meant by per-branch commit rules? I plan on using branching
=>> =>> even
=>> =>> though we're not yet using it.
=>> =>
=>> =>Do you want some people to be allowed to commit to some branches but
=>> =>not to others?
=>>
=>> Ah. Now I C sez the blind man. I do want to do that but I already have a
=>> whizkeen per-branch locker I wrote in perl (let me know if anyone wants
=>> it). Is there anything that precludes me from using my old locker?
=>
=>Not a problem!  There's nothing that keeps you from using your own
=>locker. :)  I'd love to see it.

I put it up here:

http://steveo.syslang.net/lockBranch

The invocation in the commitfile is

ALL     /path/to/lockBranch repname $USER

(We have multiple repositories here so we need to pass in the repname to
decide on what to do.)

It looks in $repos/CVSROOT/lockedBranches directory for permisssion on who
is allowed to check in and who is not. If a file exists with the same name
as the branch that you are trying to check into, then that branch is
locked. If that file contains your username, then you are the exception
and may proceed.

An entry in the file can either be a name or dir:name. In the former case
name is allowed to commit in the branch. In the latter case name can only
commit to dir.

The file that is looked ot for the main trunk is HEAD.

My perl is not as strong as I'd like so criticism happily accepted.

--
Time flies like the wind. Fruit flies like a banana. Stranger things have  .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net

On Thu, 2005-08-11 at 13:09, Steven W. Orr wrote:
> On Thursday, Aug 11th 2005 at 13:06 +1200, quoth Bruce Hoult:
>
> =>On 11/08/2005, at 12:58 PM, Steven W. Orr wrote:
> =>
> =>> Not quite there yet. I need just a *little* bit more before we get
> =>> clear
> =>> as mud ;-)
> =>>
> =>> What is meant by per-branch commit rules? I plan on using branching
> =>> even
> =>> though we're not yet using it.
> =>
> =>Do you want some people to be allowed to commit to some branches but
> =>not to others?
>
> Ah. Now I C sez the blind man. I do want to do that but I already have a
> whizkeen per-branch locker I wrote in perl (let me know if anyone wants
> it). Is there anything that precludes me from using my old locker?

Not a problem!  There's nothing that keeps you from using your own
locker. :)  I'd love to see it.

So, if you don't need us to do the branch locking, don't worry about
either commit.branch, or the patch! :)

Jason

On Thursday, Aug 11th 2005 at 13:06 +1200, quoth Bruce Hoult:

=>On 11/08/2005, at 12:58 PM, Steven W. Orr wrote:
=>
=>> Not quite there yet. I need just a *little* bit more before we get
=>> clear
=>> as mud ;-)
=>>
=>> What is meant by per-branch commit rules? I plan on using branching
=>> even
=>> though we're not yet using it.
=>
=>Do you want some people to be allowed to commit to some branches but
=>not to others?

Ah. Now I C sez the blind man. I do want to do that but I already have a
whizkeen per-branch locker I wrote in perl (let me know if anyone wants
it). Is there anything that precludes me from using my old locker?

--
steveo at syslang dot net TMMP1 http://frambors.syslang.net/
Do you have neighbors who are not frambors?

On 11/08/2005, at 12:58 PM, Steven W. Orr wrote:

> Not quite there yet. I need just a *little* bit more before we get
> clear
> as mud ;-)
>
> What is meant by per-branch commit rules? I plan on using branching
> even
> though we're not yet using it.

Do you want some people to be allowed to commit to some branches but
not to others?

On Thursday, Aug 11th 2005 at 11:23 +1200, quoth Jason Pollock:

=>Hi Steven,
=>
=>You only need to use the patch if you want per-branch commit rules. :)
=>If you don't want that, you don't need the patch, and can disable
=>commit.branch.  If you do want that, then you might be better off
=>considering running a server anyways.
=>
=>We don't have any newer versions of the CVS patch, there may be better
=>ways to achieve the same thing later, we haven't investigated.
=>
=>Finally, I thought there were problems with running CVS on NFS mounted
=>directories?
=>
=>You are correct, every instance of CVS that writes to the repository
=>will need to be patched to allow commit.branch to work.  If you are
=>using a server, only the server needs to be patched.
=>
=>Hopefully that makes it clear as mud.
=>
=>Regards,
=>Jason

Not quite there yet. I need just a *little* bit more before we get clear
as mud ;-)

What is meant by per-branch commit rules? I plan on using branching even
though we're not yet using it.


=>On Thu, 2005-08-11 at 05:12, Steven W. Orr wrote:
=>> I see in commit.branch that I need to change the src code for commit.c but
=>> I'm not clear on what this change accomplishes. We are not using cvs as a
=>> server. i.e., the value of our CVSROOT is a simple nfs mounted directory.
=>>
=>> Does this mean that to use cvszilla I have to patch every machine in the
=>> company? I'm not clear on which binary file I need to patch. Also, I have
=>> a couple of machines that are running cvs-1.12.9 where there is no line
=>> in commit.c that says
=>>
=>> run_arg (p->key);
=>>
=>> Is anyone out there :-(

--
Time flies like the wind. Fruit flies like a banana. Stranger things have  .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net

Hi Steven,

You only need to use the patch if you want per-branch commit rules. :)
If you don't want that, you don't need the patch, and can disable
commit.branch.  If you do want that, then you might be better off
considering running a server anyways.

We don't have any newer versions of the CVS patch, there may be better
ways to achieve the same thing later, we haven't investigated.

Finally, I thought there were problems with running CVS on NFS mounted
directories?

You are correct, every instance of CVS that writes to the repository
will need to be patched to allow commit.branch to work.  If you are
using a server, only the server needs to be patched.

Hopefully that makes it clear as mud.

Regards,
Jason




On Thu, 2005-08-11 at 05:12, Steven W. Orr wrote:
> I see in commit.branch that I need to change the src code for commit.c but
> I'm not clear on what this change accomplishes. We are not using cvs as a
> server. i.e., the value of our CVSROOT is a simple nfs mounted directory.
>
> Does this mean that to use cvszilla I have to patch every machine in the
> company? I'm not clear on which binary file I need to patch. Also, I have
> a couple of machines that are running cvs-1.12.9 where there is no line
> in commit.c that says
>
> run_arg (p->key);
>
> Is anyone out there :-(

I see in commit.branch that I need to change the src code for commit.c but
I'm not clear on what this change accomplishes. We are not using cvs as a
server. i.e., the value of our CVSROOT is a simple nfs mounted directory.

Does this mean that to use cvszilla I have to patch every machine in the
company? I'm not clear on which binary file I need to patch. Also, I have
a couple of machines that are running cvs-1.12.9 where there is no line
in commit.c that says

run_arg (p->key);

Is anyone out there :-(

--
Time flies like the wind. Fruit flies like a banana. Stranger things have  .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net