RE: Info-cvs Digest, Vol 27, Issue 61

[Matthew Herrmann]

Hi Todd,

In Windows scripting, you could make a cvs.bat which set the timezone
specifically for that application, without altering the environment of other
programs or batch scripts:

setlocal
set TZ=myUTCzone
cvs %*
endlocal

What you were suggesting with the CVS_TZ is something you could include in
this wrapper script, if necessary. You could set TZ to CVS_TZ if it existed
for the scope of the cvs application only.

I presume you're running on Linux/Unix, so I'm not sure what the equivalent
operations would be in that environment.

HTH,

Matthew Herrmann
---
Far Edge Pty Ltd
http://www.faredge.com.au/

-Original Message-
Date: Fri, 25 Feb 2005 16:28:59 -0500
From: Todd Denniston <[EMAIL PROTECTED]>
Subject: Re: CVS concept of time - time zone part 44!
To: Larry Jones <[EMAIL PROTECTED]>
Cc: info-cvs@gnu.org
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii

Larry Jones wrote:
> 
> Todd Denniston writes:
> >
> > Will there be an option I can put in my _ environment _ so all CVS 
> > commands client will show UTC times?
> 
> Most systems honor $TZ.
> 
darn, I was hoping I could have everything else work with the local $TZ and
cvs would use something like $CVS_TZ and only fallback to $TZ if $CVS_TZ was
not set.

Thanks.
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the
Power of Technology for the Warfighter




--

Message: 5
Date: 28 Feb 2005 08:33:29 -0800
From: "AccuRev" <[EMAIL PROTECTED]>
Subject: Free SCM Best Practices White Paper
To: info-cvs@gnu.org
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"

You're invited to download a free copy of Uttam Narsu's SCM Best Practices
white paper courtesy of AccuRev.

Uttam Narsu is a former Forrester and GIGA SCM analyst. The white paper has
received fabulous feedback and, as a courtesy, we thought it might be of
interest to the gnu.cvs.help community.

The white paper can be downloaded at http://www.accurev.com/wp6



--

___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs


End of Info-cvs Digest, Vol 27, Issue 61




___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

[slightly OT] Re: best production practice?

[Matthew Herrmann]

Hi,

A pragmatic way to do it is to do put updates on the server using:

cvs co -rRELEASE_20 proj

Then, ... To make a quick fix, get the latest source code on your dev
environment, bump up the version number in your dev environment (even on
your local machine running apache/iis/whatever). Tag it using cvs rtag, then
do an rdiff to examine changes. Go through any change procedure (which for a
single textbox caption should not be too onerous).

Then, update the production server using:

cvs up -rRELEASE_21

It shouldn't be too hard. The key is to make sure there is an easy place to
edit the site in a dev environment. So, for a start -- don't version control
the database config files or you'll have pain where prod and dev are
fighting over which database connection to use. People can then go up and
fiddle with the labels in 5 seconds -- but it doesn't show up to customers
until you hit the big button.

If you make it easy for people they shouldn't complain. You definitely want
a release controlled environment, but at the same time, a system which
involves lots of work just to change a single line of code is problematic
and needs to be automated at some level (the grunt work, not the decisions,
that is).

Another thing -- don't be shy about creating versions: there's no problem
with making several hundred versions which include nothing more than minor
fixes to things here and there. Given that, no prob in making a script which
fetches all tags, gets the highest release number, tags the next increment,
and spits out a diff and patchset onto the desktop. People will love you for
it. :)

My 5 new/250 old francs,

Cheers,

Matthew Herrmann
---
Far Edge Pty Ltd
http://www.faredge.com.au/

Level 6, 35 Chandos Street
St Leonards 2065
Ph: +612 8425 1400 
 

-Original Message-
bobby temper wrote:
> 
> Hello,
> 
> Thanks for the answers.
> 
> I also agree with Jim, but it might be hard to convince content people
that
> they have to go throught a staging first, for simple stuff. I will
definitly
> do whatever i can, tho :).
> 
> Todd, what you're saying refers actually to what i'm asking: the
production
> code is a checked out copy? (with the cvs folders, etc...). We already
have
> a tag/branch procedure. The problem is, as now, we have a "cvs export"
copy
> on production (and no cvs client on production either...). I'm wondering
if
> it would be better to install a cvs client, and have the code being a "cvs
> checkout" copy. That way, we could do like you're proposing, with cvs
diff.
> I'm actually just wondering if doing it that way has some drawbacks, vs
> doing a "cvs export/tar-gzip/scp" procedure.

OUCH.
OK, I am sometimes considered an SOB by those that work with me when it
comes to releases, but it sounds like it is time for 
1) the production machine to have the number of user names reduced to
root+otherinstalleddefaultusers & projectadmin

or
2) the production area locked down so only root & project admin can make
modifications. 

If I was the person who had to answer "what is in the production machine
today?", I would make three documents 
document 1) I, [my name], have permission to [insert lock down method] the
production [machine|area], and anyone who subverts that gets [insert
appropriate punishment]. This will be implementing an industry best practice
[site sources (besides/in addition to Jim & me)][1]
boss_signature_hereDate.

document 2) I, [my name], am not responsible for the content of the
production machine even though it has been suggested to customers we have
someone in that job. boss_signature_hereDate.

document 3) I, [my name], have informed [boss's name] that the production
[machine|area], is out of control, and anyone with [insert level of access]
can modify it at will and the changes will not be recorded in version
control, so we can not track who or when a change was made. I, [my name],
have informed [boss's name] of the following method for correcting the
situation and been denied. [insert method(s) here]
boss_signature_hereDate.

I would then take them to my boss, and indicate s/he should pick one and
sign it. BTW I am camping as physically close to my boss's person as is
possible during working hours until one is signed. :)

1 gets you the ability to fix the problem.
2 indicates it should not be your butt that is the one to kick if there is a
problem with what is on the production machine/area.
3 indicates the boss's butt is the one to kick _if/WHEN_ there is a problem
with what is on the production machine/area.
If the boss refuses to sign any of them... 
1) email the concerns and fixes to the boss, and print a copy.
2) keep a note book recording the documents, the email & when they were
presented.  
3) consider if it is worth going to the bos

RE: Info-cvs Digest, Vol 18, Issue 34

[Matthew Herrmann]

Hi,

Run this python script from within a checked out sandbox. It will create a
file called table.txt. Load this file into excel and use PivotTables to get
statistics. (This is called DataPilot in OpenOffice.)

If you don't know what Pivot Tables are, the following link will be of
assistance:

http://www.ozgrid.com/Excel/PivotTables/ExCreatePiv1.htm

Essentially you can find out:
- How many lines of code have been written per month/week/year? (+ graph)
- Drilldown on lines of code by each developer in any period
- What percentage of code is written on the trunk vs branches?

Python script below. Your newsreader may have wrapped some lines so watch
out.

You will also need to edit the list of extensions. I currently have it so it
filters to only count vb source files. This means I don't count adding a
large binary file as a large dose of productivity! (just change one of these
to .java if you're working on java code).

I tried out other cvs stats tools but they were too top-heavy. I've found
this gives me more flexibility.

HTH,

Best Regards,

Matthew Herrmann

Far Edge Technology
http://www.faredge.com.au/




# cvsstats.py
#
# Exports stats from cvs in a format which can
# be read by pivottables in excel.
#
# (C)Copyright Matthew Herrmann, Far Edge Pty Ltd 2004
#
# Comments : [EMAIL PROTECTED]
#
# May be freely used and distributed.

import os
import re

newFile = re.compile("(Working file: )(.*)")
info = re.compile("date: ([^;]+);  author: ([^;]+);  state: Exp;  lines:
\+([^ ]*) -([0-9]*)$")
revision = re.compile("revision ([0-9.]*)")

os.system("cvs log -N > ~tmp.txt")

out = open("table.txt","w+")
f = open("~tmp.txt")
filename = ""
out.write("Filename\tDate\tDeveloper\tAdded\tRemoved\tOptimistic\tPessimisti
c\tLocation\tRevision\n")
for line in f.readlines():
if newFile.match(line):
filename = newFile.match(line).groups(0)[1]
filename = filename.lower()
print "Reading " + filename + "..."

if revision.match(line):
rev = revision.match(line).groups(0)[0]
onBranch = rev.count('.') > 1

# only consider certain files as changes
if filename:
if filename.endswith(".bas") or \
filename.endswith(".cls") or \
filename.endswith(".frm") or \
filename.endswith(".ctl") or \
filename.endswith(".mst") or \
filename.endswith(".inc") or \
filename.endswith(".bat") or \
filename.endswith(".vbs") or \
filename.endswith(".iss") or \
filename.endswith(".xsl") or \
filename.endswith(".js") or \
filename.endswith(".py"):

if info.match(line):
data = info.match(line).groups(0)
out.write(filename + '\t' + data[0] + '\t' + data[1] + '\t'
+ \
data[2] + '\t' + data[3] + '\t' + str(int(data[2])+
int(data[3])) + \
'\t' + str(int(data[2]) - int(data[3])) + \
'\t' + {0:'Trunk',1:'Branch'}[onBranch] + \
'\t' + rev + \
'\n')


f.close()
out.close()


-Original Message-
Message: 8
Date: Wed, 19 May 2004 12:18:56 +0100
From: Ramanuj Singh <[EMAIL PROTECTED]>
Subject: reports in CVS
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"

How to generate reports in CVS.



The information transmitted is intended only for the person or entity to
whom it is addressed and may contain confidential and / or privileged
Material. Any review, re-transmission, dissemination or other use of or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from your
computer. Thank you for your understanding & co-operation.


-- next part --
An HTML attachment was scrubbed...
URL:
http://mail.gnu.org/pipermail/info-cvs/attachments/20040519/f2db48cf/attachm
ent.html



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

move away ... it is in the way

[Matthew Herrmann]

Hi All,

Am getting the following behaviour with a resurrected file. When I run cvs
up, it tells me a file is in the way. I delete it, and it creates a new file
which it still considers in the way.

I can throw away my sandbox but it has already happened on a larger scale to
another developer and I want to find a definitive solution before it trashes
someone's work in progress.


Client: Concurrent Versions System (CVSNT) 2.0.11 (client/server) Windows
2000
Server: CVS 1.11.9 (on Redhat)


Transcript
==
>cvs up
cvs update: move away ./32-well Rotor.jpg; it is in the way
C 32-well Rotor.jpg

>del "32-Well Rotor.jpg"

>cvs up
cvs update: warning: 32-Well Rotor.jpg was lost
U 32-Well Rotor.jpg
cvs update: move away ./32-well Rotor.jpg; it is in the way
C 32-well Rotor.jpg
===


Status:

>cvs status "32-Well Rotor.jpg"
===
File: 32-Well Rotor.jpg Status: Up-to-date

   Working revision:1.2.2.2
   Repository revision: 1.2.2.2 /.../
32-well Rotor.jpg,v
   Sticky Tag:  VER_PATCHES (branch: 1.2.2)
   Sticky Date: (none)
   Sticky Options:  -kb


Corresponding entry in CVS\Entries:

/32-Well Rotor.jpg/1.2.2.2/Mon May 17 05:16:25 2004/-kb/TVER_PATCHES




Any help appreciated,


Matthew Herrmann

Far Edge Technology
http://www.faredge.com.au/



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

RE: Fw: need to force username of cvs 'action' when using shared SSHaccount

[Matthew Herrmann]

Hi Tim,

Ironically enough, exactly what you are asking for is pserver access.
Because the username can be fairly easily overridden in this method, it's
not considered secure (but in a normal work environment it's fine). The ssh
method of connecting is secure for the precise reason that secure is managed
outside cvs and it _won't_ let you get around it.

The only other suggestion is to add a commit-check which ensures that the
username is present in the commit message. You can set up a template which
commit messages must conform to, and then change the cvs editors on each
developer box so the pre-generated form comes up each time.

This is a hack, but I can't see how you can do what you're after otherwise.

Best Regards,

Matthew Herrmann

Director
Far Edge Technology
http://www.faredge.com.au/

-Original Message-
Date: Sun, 2 May 2004 11:33:46 -0400
From: "Tim Grotenhuis" <[EMAIL PROTECTED]>
Subject: Fw: need to force username of cvs 'action' when using shared
SSHaccount
To: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain;   charset="iso-8859-1"

> >
> > Is there a reason why you can't use the old-fashioned strategem
> > of one account per developer ?

 My ISP won't give me additional accounts.

> > You can also use $HOME/.ssh/environment on the client side to tunnel
> > environment variables of your choice.  I've never tried it myself, I
> > just saw that in the ssh man page.  (Your developers would be able to
> > cheat, though.)  The trouble is, CVS doesn't look at the environment to
> > decide who's calling.

 My script that runs in the command="" option in the authorized_keys2 file
 runs successfully and I can control the input based on which key (ie, which
 developer) is used.  I am looking for the correct environmental variable
 that CVS WILL look at.

> >
> > > There HAS to be a way to force cvs to record the correct committer
> > > name.
> >
> > Why ?  Why would cvs extract that information from a source other than
> > its own euid ?

 I just can't imagine that this hasn't been required before: a single shell
account with a used id of, for example,  'cvsuser' requiring SSH, instead of
pserver, authentication and access for developers.  The nature of CVS, that
of tracking diffs and who did what when, seems to be compromised in this
situation.  Thats all.



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

Accessing CVS through SQL Server

[Matthew Herrmann]

Hi Chandra,

I've posted your question on info-cvs in case it applies to others.

If you would like to access cvs through a stored procedure, then the
following applies:

The first step i would recommend is to make a batch program which outputs
all the commandline parameters and then pauses:

echo %*
pause

Run this from SQL Server's xp_cmdshell and see what you get. If no
parameters come through, you'll need to look up parameter passing in SQL
Books online. If that works, have the batch script run cvs as a next step.
If you get that working, then try substituting cvs.exe for the program you
are running.

As for using cvs with SQL Server, I posted a script called GenerateSQL.vbs
which took all the scripts from a repository and dumped them in a
(more-or-less) canonical form, it should be somewhere in the archives.

HTH,

Matthew Herrmann

Far Edge Technology
http://www.faredge.com.au/

-Original Message-
From: Chandra Sekhar [mailto:[EMAIL PROTECTED]
Sent: Monday, 5 April 2004 9:40 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: chandrasekhar request


Hi sir,

I encountered a problem which is similar to yours which i found in
FAQ's.
I'm in need of some assistance regarding usage of cvs commands in
sqlserver.
i tried with xp_cmdshell. i'm getting the results for cvs --help
command.

but i need to login through sqlserver. please do me a favor in this
regard.

thankful to you.

chandrasekhar






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

RE: cvs rlog -rTAG1::TAG2 doesn't handle newly added files

[Matthew Herrmann]

Hi Larry,

But the problem of missing tags should only come up when a file initially
doesn't exist, and then does. The reverse cannot happen because the dead
revision should still be tagged, shouldn't it(?) if the file is removed via
cvs rm. The only exception would be a faulty tagging process where the file
wasn't tagged with others. In that case I would say it's a faulty behaviour
coming from incorrect use. The alternative of faulty behaviour from correct
use is more serious.

The branching problem you mentioned doesn't come up for the coming up into
existence problem, because every file always starts from 1.1. Said another
way, every file has a single beginning, but multiple possible ends.

In this case, my suggestion of selecting every revision up to the end tag
makes sense, doesn't it?

People's thoughts?

-- Matthew


-Original Message-
From: Larry Jones [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 3 December 2003 7:48 AM
To: Matthew Herrmann
Cc: CVS Mailing List
Subject: Re: cvs rlog -rTAG1::TAG2 doesn't handle newly added files


Matthew Herrmann writes:
>
> I upgraded to 1.11.9 but this didn't solve the problem.

Sorry, I knew there were a number of fixes to that code and I was hoping
that they would fix the problem.  Now that I think about it a bit more,
however, I don't think it's fixable.  I don't think there's any way for
CVS to intuit, in the general case, what a missing tag should mean.  For
example, if it's the end tag that is missing and there's more than one
branch past the start tag, which branch should CVS follow?

-Larry Jones

Oh, now don't YOU start on me. -- Calvin



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

RE: cvs rlog -rTAG1::TAG2 doesn't handle newly added files

[Matthew Herrmann]

Hi All,

I upgraded to 1.11.9 but this didn't solve the problem.

Maybe the fix in 1.11.9 for this problem was only for the precise case where
the file was created after, but wasn't modified?

In any case, to reproduce, copy the following into a working directory. 3
revisions should be displayed by the log command at the end, but none are :

echo 1 > test.txt
cvs add test.txt
cvs commit -m "test.txt"
echo 2 > test.txt
cvs commit -m "test.txt"
echo 3 > test.txt
cvs commit -m "test.txt"
cvs tag TEMP test.txt
cvs log -rBEFORE::AFTER test.txt


Output:
cvs log: warning: no revision `PRIOR_TAG' in `...,v'

RCS file: /.../test.txt,v
Working file: test.txt
head: 1.3
branch:
locks: strict
access list:
symbolic names:
TEMP: 1.3
keyword substitution: kv
total revisions: 3; selected revisions: 0
description:
========
=


Best Regards,

Matthew Herrmann

Far Edge Technology
http://www.faredge.com.au/

-Original Message-
From: Matthew Herrmann [mailto:[EMAIL PROTECTED]
Sent: Thursday, 27 November 2003 11:32 AM
To: Larry Jones
Subject: RE: cvs rlog -rTAG1::TAG2 doesn't handle newly added files


thanks once again for your help Larry!

-Original Message-
From: Larry Jones [mailto:[EMAIL PROTECTED]
Sent: Thursday, 27 November 2003 1:34 AM
To: Matthew Herrmann
Cc: [EMAIL PROTECTED]
Subject: Re: cvs rlog -rTAG1::TAG2 doesn't handle newly added files


Matthew Herrmann writes:
>
> I'm having problems with cvs rlog and -rTAG1::TAG2 not outputting changes
> for newly created tags.

Update your server to the most recent release (1.11.9).

-Larry Jones

Do you think God lets you plea bargain? -- Calvin



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

cvs rlog -rTAG1::TAG2 doesn't handle newly added files

[Matthew Herrmann]

Hi All,

I'm having problems with cvs rlog and -rTAG1::TAG2 not outputting changes
for newly created tags. I can't use cvs rdiff -s since I'm feeding the
output into cvs2cl --xml.

Versions:
Client is 2.0.11 CVSNT (Windows 2000)
Server is 1.11.2.1 (Linux)

Here are steps to reproduce:

1. rtag module with TAG1. File Blah.txt doesn't exist yet.
2. Add Blah.txt to repository, make a couple of changes, Blah.txt now 1.3.
3. rtag module with TAG2.
4. Run cvs rlog -rTAG1::TAG2 module
5. The changes to Blah.txt will not appear because TAG1 didn't exist before.

This seems inconsistent with behaviour of other parts of cvs, and certainly
breaks my changeset roll-forward/roll-back scripts.

To my understanding, the logic to fix this would be:

- If TAG2 exists on file, but not TAG1, then act as if the file were tagged
version before revision 1.1. Therefore, -rBEFORE::1.1 would return the
changes for 1.1 for that file. I think that would work for branches too
since there should at least be a phantom copy of the file if it was in the
repository, but deleted.

Does this sound right?

TIA for any assistance,

Matthew Herrmann

Far Edge Technology
http://www.faredge.com.au/



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

RE: Info-cvs Digest, Vol 11, Issue 3

[Matthew Herrmann]

Hi Rod,

If you don't need file merging, then I suggest creating a script which is
stored in the customisations, which automatically checks out the required
version and performs the xcopy across. We do a similar thing in our
"release" script for our software -- it checks out the version to release,
runs the test cases, compiles and packages. You may even be able to do
something more exciting using the "modules" file, though it has some strange
limitations -- so your mileage may vary. This is suitable if the changes are
quite loosely coupled.

Another approach which does what you want is a checked out CVS folder for
each customer. Every time you run "cvs up", it will get the latest updates
from the main branch. You would never commit from these folders. This is
basically a way to simulate vendor branches without going down that path.
The drawback with this is that you lose your ability to version control your
vendor files (unless you store them as a series of tar files containing
working directories).

Yet another, but more hands-on approach requires storing diff3 files, and
their ancestor. Effectively, it gives you a CVS ancestor behaviour without
the extra baggage. I use this for modifications I make to generated code,
though it could also work for cases like yours. It's only suitable where
there are a small number of files being modified, since the set-up is
explicit (far cry from xcopy).

All depends on the complexity of the customisations you're doing.

HTH,

Regards,

Matthew Herrmann
--
VB6/SQL/Java/CVS Consultancy
Far Edge Technology
http://www.faredge.com.au/

-Original Message-
Date: Sat, 4 Oct 2003 11:06:18 -0700
From: "Rod Macpherson" <[EMAIL PROTECTED]>
Subject: Branch Manager
To: <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"

Apologies in advance if this is the wrong mailing list but it's the only
one that looked promising.

We have a base set of files that we customize on a per-client basis.
Each client has a mirror image of the base directory structure. Each
client does not have a mirror image of the base files but rather only
those files that require customization exist in the client directory
tree. Prior to building a client we merge the client tree with the base
tree using a simple recursive copy and then build. That simple approach
is well organized and effective however there are some drawbacks.

This is not the typical branching situation since there will never be
any merging of client code back in to the main trunk. There is also
resistence to using CVS branches since everybody contributing to the
project (content developers, technical writers) must now manage branch
labels versus just plopping changes for Acme in the Acme folder. I would
really be interested in hearing from anybody who has ideas on managing
highly selective client changes for a large number of clients.

TIA

Rod



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

updated to 1.11.6 (from 1.11.2) now have problems on windows

[Matthew Herrmann]

I'd be inclined to agree here. One particularly common use case for having
files with different casings is when a file is incorrectly cased on first
commit.
One runs cvs rm, renames the file then re-adds it (as following the "right
way" of doing things). In this case, there is never a sandbox conflict as to
which file is meant by the particular revision.

If there was to be a check on the cvs server, I would much prefer something
which forced files on windows machines to be committed using the same
case as an existing file on another branch. I frequently have problems with
"build.bat" being created on one branch, and "Build.bat" being made on the
trunk, then avoiding all the rcs_assert( != 0) errors that appear if things
are
not handled very sensitively.

-Original Message-

> The existing (I think) test cares about theoretical ambigity; my
> proposed one cares only about the practical problem -- the
> impossibility of stuffing two unrelated revisions into one
> sandbox file.  If an operation isn't trying to do that,
> forbidding it on theoretical grounds seems pointlessly annoying.



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

RE:how to roll-back whole commit operation

[Matthew Herrmann]

Hi Craig,

Can't think of an easy way of doing it with cvs out of the box. Try this
tool we developed at our shop which I use very frequently for this precise
purpose:

http://www.matt.faredge.com.au/htmlchangelog.zip

You need to have cvs2cl installed on your pc. It will basically use that
internally to extract a commit-by-commit changelog in xml.

Once you run it, it generates a nice looking webpage of changes, where you
can output the cvs statements to roll back, roll forward (to move changes
between branches) or diff (for code review).

If you're not on windows, you'll need to rewrite the wrapper batch files for
linux but that should be pretty straightforward.

HTH,


Matthew Herrmann
--
VB6/SQL/Java/CVS Consultancy
Far Edge Technology
http://www.faredge.com.au/

--

Message: 9
Date: Mon, 15 Sep 2003 12:58:44 -0400
From: "Dickson, Craig" <[EMAIL PROTECTED]>
Subject: how to roll-back whole commit operation
To: "CVS List (E-mail)" <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"

What is the easiest way to roll-back a commit operation? I know when the
commit happened and nothing has changed on that branch since the commit
happened? I could use update with 2 -j options, but there is over 150
changes in the commit, so I would have to do it once for each file if I
understand it correctly since they all have difference revision numbers. Is
there are way to update my working directory "backwards" so to speak?



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

RE: Info-cvs Digest, Vol 9, Issue 4

[Matthew Herrmann]

Hi Gu,

These are intermediate files used by C++ to make builds quicker that you
don't need to keep in CVS. You're better off adding them to your .cvsignore
file instead.

HTH,

Matthew Herrmann
--
VB6/SQL/Java/CVS Consultancy
Far Edge Technology
http://www.faredge.com.au/


-Original Message-

Message: 3
Date: Mon, 4 Aug 2003 21:52:41 -0400
From: "Mark Priest" <[EMAIL PROTECTED]>
Subject: Re: file changed in cvs-1.11.5 on win2k
To: "Gu Shaodong" <[EMAIL PROTECTED]>,  <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain;   charset="gb2312"

Gu,

I believe these are all binary files.  You should have added them to cvs
with cvs add -kb so that keyword expansion was turned off and the file was
recognized as  binary.  By default cvs assumes file are text and attempts to
expand keywords such as $Author$, $Revision$, etc.  It also assumes files
can be stored in the repository using RCS format which includes the current
version plus all of the deltas in the same file.  You can fix this by
running the admin command against a correct version of the files (i.e. cvs
admin -kb foo.pdb) or by removing them and adding them again using (rm
foo.pdb, cvs remove foo.pdb, then cvs add -kb foo.pdb).

-Mark

- Original Message -
From: "Gu Shaodong" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, August 04, 2003 9:14 PM
Subject: file changed in cvs-1.11.5 on win2k


> Hi, guys:
>
> I'm not sure whether my question has been asked for many times or not.
> If so, please tell me where I can find the solution. Thanks.
>
> I got a problem when using cvs-1.11.5 on win2k sp4.
> After importing a vc6 workspace including several projects into cvs,
> some file changed when I check out this tree later.
> changed file: some .pdb, .ico, .bmp (maybe some other files I didn't
> find out)
> Any help or advice ?
>
> TIA
> -gusd
>
>
>
>
> ___
> 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

Adding files on branch off a branch

[Matthew Herrmann]

Hi All,

If I create a new file on a branch of a branch, it creates a 3-digit branch
(ie 1.1.2), and not 5 digit ones like all the other files which were already
on the first branch and were then subsequently modified.

I think this is because the simple handling of newly created files just adds
a deleted revision 1.1 and then resurrects it on the branch.

My question is, when I then merge back onto my first-level branch, it will
try to resurrect the 1.1 file from the trunk, won't it? But that revision
number will already have been taken by the branch of the branch. So either
it will have to give it an unrelated number, which breaks the idea that
1.1.2.4.5.6 is always a descendent of 1.1.2.4, or it will clash on the
revision number of the existing branch and crash.

Am I on track here?

TIA,

Matthew Herrmann
--
VB6/SQL/Java/CVS Consultancy
Far Edge Technology
http://www.faredge.com.au/



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

bug in branch switching behaviour

[Matthew Herrmann]

Hi All,

I'm having exactly the same problem as Jo in this post:

http://groups.google.com.au/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&thre
adm=6vjf5k%24p5t%40magus.cs.utah.edu&rnum=1&prev=/groups%3Fq%3Ddummy%2Btimes
tamp%2Bfrom%2Bnew-entry%2Bconflict%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF
-8%26safe%3Doff%26selm%3D6vjf5k%2524p5t%2540magus.cs.utah.edu%26rnum%3D1

my sequence of steps was:

- current sandbox on branch BRANCH
- cvs update
- resolve conflicts -- don't commit! (need to put it on the branch)
- cvs rtag -rBRANCH -b NEW_BRANCH project
- cvs up -rNEW_BRANCH
- cvs commit

Fails with 'filename' had a conflict and has not been modified. These files
do not have any conflict markers any more, so it must be due to the "dummy
timestamp new-file" entry put in the entries file.

Are there any fixes yet for this in the newer versions?

I'm using CVSNT 1.11.1.3 client and server Linux CVS 1.11.2.1 with the 3-way
diffs patch.

TIA,

Matthew Herrmann
--
VB6/SQL/Java/CVS Consultancy
Far Edge Technology
http://www.faredge.com.au/



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

Re: checkout

[Matthew Herrmann]

Hi Yu,

> I've been using GNU CVS for a while on and off. In my
> last project, I used the the cvs command such as "cvs
> co dummy.c" for editing the file.

Sounds like a far shot, but:

rcs co blah.c

will check out blah.c for editing and make it read-write -- exactly the
behaviour described. Is there a possible confusion between rcs and cvs?

Regards,

Matthew Herrmann
--
VB6/SQL/Java/CVS Consultancy
Far Edge Technology
http://www.faredge.com.au/

-Original Message-

Message: 4
Date: Fri, 1 Aug 2003 16:01:43 +1000
From: JacobRhoden <[EMAIL PROTECTED]>
Subject: Re: checkout
To: [EMAIL PROTECTED], Mark Priest <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain;  charset="iso-8859-1"

On Fri, 1 Aug 2003 02:30 pm, Y Hu wrote:
> I know "cvs co module" works, it checks out the whole
> directory. Now, the real question is how do you check
> out a file for editing? I thought "cvs co dummy.c"
> changes a read-only file dummy.c to a read-write file
> in my local directory, so that I can edit the dummy.c
> in my local directory. If I use "cvs update dummy.c",
> it won't change the read-only attribute. What is the
> GNU cvs command to check out a file for editing?

cvs doesn't work like that, to edit a file you just edit it, then type cvs
commit. As long as the file is in the directory, it is ready for editing. It
is done like this so that more than one person can have the same file
checked
out and edit it at the same time (:





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

RE: Info-cvs Digest, Vol 8, Issue 6

[Matthew Herrmann]

> Yes, but what if someone commits something between when you decide to run
> the rtag and when you actually run it? That is the danger.

This is a danger only if a release is made and then its contents is not
tested or examined at all afterwards. The key is to tag first and then test
and write release documentation afterwards.

Our process here is:

- create a tag using 'cvs rtag' (on branch usually, or HEAD for bleeding
edge)
- get changes between last release and proposed new release
- code review the diffs for change patches (using HTMLChangeLog.xsl)
- test impact of all changes

We then write up release documentation for users. The key is to have a very
clear idea of what it is you are releasing. Without examining each change,
it is just crossing one's fingers anyway.

Using "cvs tag" bases what is released on the checked out revisions of a
certain user's sandbox, which is a complex notion and easy to stuff up,
given cvs's architecture. Users can forget to run "cvs update", and so miss
a bug fix which was supposed to be included in a release. Users may not
include "cvs up -d" and so exclude certain files from a revision because
directories are missing (but another precompiled binary is in their path so
the app still 'seems to work fine'). Users can tag a revision from within a
subtree of the project and thus also create a garbage version. There is no
notion of a particular "state" of a sandbox, so there is no real way of
knowing what you are tagging, it is just some particular point in time when
you happened to check out from the repository.

To me tagging a checked out version feels a bit like: "I checked out the
code, played with it on my computer for 20 minutes and it seemed to work,
let's release exactly that before anyone touches anything". (But that's my
view.)

My 5 cents,

Matt

-Original Message-
From: Max Bowsher [mailto:[EMAIL PROTECTED]
Sent: Saturday, 12 July 2003 18:08
To: Matthew Herrmann
Cc: [EMAIL PROTECTED]
Subject: Re: Info-cvs Digest, Vol 8, Issue 6


> -Original Message-
> From: Larry Jones [mailto:[EMAIL PROTECTED]
...
> Why?  It's "cvs rtag" when used without the -r option that's truely
> dangerous, since you have no way of knowing what revisions you're
> tagging.

Matthew Herrmann wrote:
> I always understood that "cvs rtag" without a "-r" would tag the latest
> version of all files on the trunk, synonymous with "cvs rtag -rHEAD
tagname
> module" (?) I had been using it in this manner for some time and not
> experienced behaviour to contradict this.

Yes, but what if someone commits something between when you decide to run
the rtag and when you actually run it? That is the danger.

Max.




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

RE: Info-cvs Digest, Vol 8, Issue 6

[Matthew Herrmann]

If 'cvs tag' is run from a subdirectory of within a large directory
structure, only files within that section will be given the tag -- that
subdirectory is treated like a module. No error appears because this
operation is valid. Later, when trying to diff between versions of the
software, lots of spurious changes will come up due to the incorrect
tagging. With "cvs rtag", the user is forced to tag every file in the entire
repository.

I always understood that "cvs rtag" without a "-r" would tag the latest
version of all files on the trunk, synonymous with "cvs rtag -rHEAD tagname
module" (?) I had been using it in this manner for some time and not
experienced behaviour to contradict this.

Matthew Herrmann
--
VB6/SQL/Java/CVS Consultancy
Far Edge Technology
http://www.faredge.com.au/

-Original Message-
From: Larry Jones [mailto:[EMAIL PROTECTED]
Sent: Sunday, 6 July 2003 09:43
To: Matthew Herrmann
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Info-cvs Digest, Vol 8, Issue 6


Matthew Herrmann writes:
>
> The only caveat to this approach is that "cvs tag" should not be used,
only
> "cvs rtag" since you risk polluting your utils project with TAGS from
> multiple projects otherwise. This caveat is not a drawback for me since I
> consider "cvs tag" a dangerous option.

Why?  It's "cvs rtag" when used without the -r option that's truely
dangerous, since you have no way of knowing what revisions you're
tagging.

-Larry Jones

Even if lives DID hang in the balance, it would depend on whose they were.
-- Calvin



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

RE: Info-cvs Digest, Vol 8, Issue 6

[Matthew Herrmann]

Hi Jeff,

(...my input into the debate)

The best way IMHO to do such code sharing is to mimic the behaviour of the
'modules' command by including the following in your build script:

cvs co utils

-- this variant means that this code is designed to run on the absolute
latest version of utils.

cvs co -rUTILS_13 utils

-- this means that this code is designed to run with a particular version of
the utils project.

The nice thing about this setup is that:

- you can explicitly toggle between 'bleeding-edge' and precise version
control, where-as shared files leave the difference between these two
concepts hazy indeed.

If multiple people are working on the shared project, you can have a
controlled process where you 'move' from version 13 to 14 of the utilities,
and test for incompatibilities.

The only caveat to this approach is that "cvs tag" should not be used, only
"cvs rtag" since you risk polluting your utils project with TAGS from
multiple projects otherwise. This caveat is not a drawback for me since I
consider "cvs tag" a dangerous option.

Cheers,

Matthew Herrmann
--
VB6/SQL/Java/CVS Consultancy
Far Edge Technology
http://www.faredge.com.au/

-Original Message-

Date: Fri, 4 Jul 2003 11:00:56 +0800
From: Jeff Pitman <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Sharing files across directories - Redux
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain;
  charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Message: 1

A bit of a delayed response, I know...

At 02:33 PM 9/25/2002, Matt Lyon wrote:

> Is there a way to share a single source file across multiple
> directories in CVS, so that if it gets committed/merged in one
> directory the update registers in both locations? I know that VSS has
> this concept, and was wondering if CVS offers any sort of similar
> functionality. I was thinking that perhaps this could be achieved with
> some symlink trickery on the server-side?

On Wed, 25 Sep 2002 17:26:09 -0400, Frederic Brehm wrote:
> Actually, Ampersand modules share whole directories, not single files.
> CVS has no built-in way to share a single file across multiple
> directories.

I was able to successfully share a single file by using some hackery in
the CVSROOT/modules and Ampersand modules.  But, it doesn't scale very
well, so I recommend it only if you need to share a couple of files.
The scaling problem comes when you have to begin using a complex
mneumonic/keyword system to cross-merge similar files across different
directories from different projects.

Some more disadvantages:

* You cannot use branching to coax a different set of files to come out
* You cannot re-check out the repository into your working copy and
have clean output.  You will always get conflicts (even though it isn't
real.)

Use this only when absolutely necessary.  Otherwise, follow Frederic's
recommendation about changing the build system to accomodate your
needs. (Eg. KDE does a symlink in the Working copies of their many
projects to the admin/ directory to share the autoconf stuff around.)

Steps to share one file (all by editing CVSROOT/modules):

1. Add your project module and point to an Ampersand module:

# '-d' added for completeness, although optional
# Alias Working dir.Repos. Module   Files or & Modules
foobar  -d foobar   foobar  &shared-admin &shared-init

2. Select the files and location where you want to put this.  It will
have to be a sub-directory off of the Working copy's root.

shared-admin -d admin   baseline/admin  ltmain.sh missing
shared-init-d src   baseline/srcmain.c init.c

Note: CVS admin directories for autoconf probably could just as well be
shared as a whole, instead of individual files.  Therefore, the second
"shared-init" provides a more interesting example where it can
cross-mix different files between a set of baseline files and a set of
project specific files.  Of course, branching and merging is left as an
exercise for the reader!!

Definitions:

Alias   - Used to link modules together, used only under the scope of
CVSROOT/modules.
Working dir. - The name of the directory that is output starting at the
base of your checkout.
Repos. Module - The repository module or its subdirectory
Ampersand (&) Modules - a link to another Alias found in CVSROOT/modules
Files - files that are found under the listed Repos. Module

I hope this has been an informative piece. Let the debate begin!

take care,
jeff



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

RE: Info-cvs Digest, Vol 7, Issue 54

[Matthew Herrmann]

Hi Ben,

Our company developed an HTML changelog facility. It uses cvs2cl.pl's xml
output to give HTML changeset information with inspection of individual
commits, rollback and roll forward (for moving changes between branches).
You might find this method the easiest way to export data into an access db
or excel or something to do pivot-table analysis there.

The key to the problem is -- how to get the change info out of CVS in a
structured manner, which cvs2cl does very nicely. Our stylesheet thus is
essentially trivial in nature.

It's available at:
http://www.matt.faredge.com.au/HTMLChangeLog.xsl

Regards,

Matthew Herrmann
--
VB6/SQL/Java/CVS Consultancy
Far Edge Technology
http://www.faredge.com.au/

-Original Message-

Date: Mon, 30 Jun 2003 12:10:40 +0100
From: "Hill, Benjamin W" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: RE: Help: Obtaining User Changes
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain
MIME-Version: 1.0
Precedence: list
Message: 5

This has made me think...

Are there any good tools that can generate HTML reports from CVS ChangeLogs?

I'd be looking for something that generates in tabular form, a report that
would list the updates to files, and activity percentile of authors. I know
there is view CVS, but would it do this job?

Cheers,

Ben



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

RE: Info-cvs Digest, Vol 7, Issue 25

[Matthew Herrmann]

Hi,

People have been confusing windows 2000 and Windows 98 here.

On windows 98, you need to edit your Autoexec.bat file to include
the line:

SET CVSROOT=blah

On Windows 2000, it's in Control Panel, System, Advanced, as was
mentioned.

HTH,

Matthew Herrmann
--
VB6/SQL/Java/CVS Consultancy
Far Edge Technology
http://www.faredge.com.au/


--

Date: Fri, 13 Jun 2003 07:52:49 -0400
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Quick Question
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Precedence: list
Message: 1


If you do it from the command line it will be reset when you reboot your
machine however.



|-+->
| |   Kristopher Hollingsworth <[EMAIL PROTECTED]>|
| |   Sent by:  |
| |   info-cvs-bounces+thomas.maciejewski=us.socgen.|
| |   [EMAIL PROTECTED]   |
| | |
| | |
| |   06/12/2003 05:56 PM   |
| |   Please respond to tiphares|
| | |
|-+->

>---
---|
  |
|
  |   To:   [EMAIL PROTECTED]
|
  |   cc:
|
  |   Subject:  Re: Quick Question
|

>---
---|




Actually... you can do it from the Command line... Just Set CVSROOT=C:
\Path Just thought I'd get that out for the Archive for setting Windows
98 Enviromental Variables.

--- [EMAIL PROTECTED] wrote:
>
>you have to be admin maybe ...
>it is under control panel - > system - > environment
>add your variable and your var name
>
>
>
>|-+->
>| |   Kristopher Hollingsworth <[EMAIL PROTECTED]>|
>| |   Sent by:  |
>| |   info-cvs-bounces+thomas.maciejewski=us.socgen.|
>| |   [EMAIL PROTECTED]   |
>| | |
>| | |
>| |   06/12/2003 04:38 PM   |
>| |   Please respond to tiphares|
>| | |
>|-+->
>  >
-



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

Re: Removing sticky tag 'HEAD' in cvs

[Matthew Herrmann]

I've had this same problem too about a month ago. It was a major pain to
work out how to fix.

Given what HEAD means, it should never make sense to run:
cvs up -rHEAD

and it should always make sense to use: "cvs up -A" instead.

Given that, can the "up -r" option refuse to take "HEAD" as a tag? HEAD is
already a 'magic' tag so it's not as if this will cause CVS to lose
generality.

If one of the cvs maintainers is listening, can this be put on the wish
list?

Thanks,

Matthew Herrmann
--
VB6/SQL/Java/CVS Consultancy
Far Edge Technology
http://www.faredge.com.au/

--

Date: Tue, 3 Jun 2003 11:45:34 -0400 (EDT)
From: [EMAIL PROTECTED] (Larry Jones)
To: [EMAIL PROTECTED] (Elijah P Newren)
Cc: [EMAIL PROTECTED]
Subject: Re: Removing sticky tag 'HEAD' in cvs
Message-ID: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]> from "Elijah P
Newren" at Jun 03, 2003 09:18:10 AM
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Message: 5

Elijah P Newren writes:
>
> At the risk of sounding really stupid (this has to have a simple
> solution), how do I remove the sticky tag of 'HEAD' from my files?

cvs update -a

> [And why is 'HEAD' a sticky tag in the first place?]

Because you did "cvs update -r HEAD".  Any time you update to a specific
revision, that revision becomes "sticky" in your working directory.
It's not that the tag itself is sticky, rather that your working file is
stuck at that revision.

>  A quick 'cvs
> update -A' does _not_ seem to work.

That's because...

>   1019 [EMAIL PROTECTED]:fluid$ cvs update -A steps.txt
>   A steps.txt

This provides the critical piece of information -- the "A" indicates
that this is a new file that has been *added* with a sticky tag.
"update -A" doesn't fix it because there's no corresponding file in the
repository to update with.  Unfortunately, I don't know of any good way
to fix it.  Probably the simplest thing to do is to temporarily rename
the file, "cvs remove" it, rename it back again and "cvs add" it (now
that your working directory no longer has a sticky tag, the file won't
get one either).

-Larry Jones

They say winning isn't everything, and I've decided
to take their word for it. -- Calvin


--

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


End of Info-cvs Digest, Vol 7, Issue 4
**



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

RE: The idea isn't clear...

[Matthew Herrmann]

I think this problem is endemic to the whole checkout-merge-commit model.
Nor Eclipse nor any other tool will be able to handle this in CVS, although
maybe it could send CVS users notifications of commits, and automatically
run "cvs up" if it was guaranteed to generate no conflicts. There's a hook
for this actually, so it could be done.

That would actually be quite a safe and useful tool, methinks -- providing
you could run hook scripts as part of the client to run your build scripts.

-Original Message-
From: Giovanni Giazzon [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 3 June 2003 22:46
To: [EMAIL PROTECTED]
Cc: Matthew Herrmann
Subject: Re: The idea isn't clear...


Hi Matthew,
I agree with you. That's why we've decided to use CVS. Besides those
conflicts problems, we have a gain in productivity since we do not have to
wait for a developer to stop editing a file. Unfortunately, the CVS Eclipse
plugin does not shows if someone is editing a file, what has made us
synchronize all the time.
Regards,
Giovanni Giazzon



- Original Message -
From: "Matthew Herrmann" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, June 03, 2003 5:03 AM
Subject: Re: The idea isn't clear...


> Hi Giovanni,
>
> The only way to prevent these conflicts is to organise from a ppl
> management perspective which developers are working on which files.
>
> If people work in a source-safe way on separate files (which happens most
> of the time), then people will not get any conflicts at all when they
> synchronize. If they get a lot of conflicts, then they would have been
> spending a lot of time waiting for each other to unlock the file so they
> could change one line, then give it back to the other guy so he adds one
> line etc.
>
> Essentially in both systems, it is a pain for 2 people to be working on
> the same part of the document : either because it is locked most of the
> time, or because of conflicts after finishing work.
>
> I like the commit merge model, because it allows users to make innocuous
> changes like changing visibility of classes others are working on without
> needing a file lock.
>
> HTH,
> Matthew
>
> Giovanni Giazzon said:
> > Yes, it has this option and it is helpful. But, it has to be called by
> > the developers so, again, bad things can happen when editing the same
> > file. Even though, we do this synchronization before edit and before
> > commit. I think that there is no way to prevent these conflicts in
> > concurrent implementation. It is something that I'm not used to, since
> > I'm coming from SourceSafe-like version control systems.
> >
> > Thanks,
> > Giovanni Giazzon
> >
> >
> > - Original Message -
> > From: "Matthew Herrmann" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Monday, June 02, 2003 2:12 AM
> > Subject: Re: The idea isn't clear...
> >
> >
> >> Eclipse goes one further and gives you an opportunity to synchronise
> >> in a clean area, where you can review changes that come in before they
> >> are automatically merged. This is better than vanilla CVS, though it
> >> is a bit slower to handle over dial-up.
> >>
> >> It should be called "synchronize with repository" option (or something
> >> similar).
> >>
> >> Essentially, each user does not need to worry about the other until
> >> they commit. The bigger the change, the more likely the last person to
> >> commit will need to resolve conflicts with other users.
> >>
> >> -Original Message-
> >> Date: Thu, 29 May 2003 14:54:40 -0300
> >> From: "Giovanni Giazzon" <[EMAIL PROTECTED]>
> >> To: <[EMAIL PROTECTED]>
> >> Subject: Re: The idea isn't clear...
> >> Message-ID: <[EMAIL PROTECTED]>
> >> References:
> >>
> >>
> >
<[EMAIL PROTECTED]><000d01c32561$8
> >> [EMAIL PROTECTED]>
> >> <[EMAIL PROTECTED]>
> >> Content-Type: text/plain;
> >> charset="iso-8859-1"
> >> MIME-Version: 1.0
> >> Content-Transfer-Encoding: 7bit
> >> Precedence: list
> >> Message: 1
> >>
> >>  "you'll get a warning about being not up to date"
> >>
> >> That would be great, but I'm working with CVS and Eclipse and that
> >> warning does not seems to exist (it's a plugin to connect to a CVS
> >> server). I did some tests here with one branch being shared between
> >> two developers, and without that "warning" things can get dangerous.
> >> But this approach looks better than the "a branch per developer" one.
> >> Does anybody have experience with CVS and Eclipse in this list?
> >> Thanks,
> >> Giovanni Giazzon
>




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

Re: The idea isn't clear...

[Matthew Herrmann]

Hi Giovanni,

The only way to prevent these conflicts is to organise from a ppl
management perspective which developers are working on which files.

If people work in a source-safe way on separate files (which happens most
of the time), then people will not get any conflicts at all when they
synchronize. If they get a lot of conflicts, then they would have been
spending a lot of time waiting for each other to unlock the file so they
could change one line, then give it back to the other guy so he adds one
line etc.

Essentially in both systems, it is a pain for 2 people to be working on
the same part of the document : either because it is locked most of the
time, or because of conflicts after finishing work.

I like the commit merge model, because it allows users to make innocuous
changes like changing visibility of classes others are working on without
needing a file lock.

HTH,
Matthew

Giovanni Giazzon said:
> Yes, it has this option and it is helpful. But, it has to be called by
> the developers so, again, bad things can happen when editing the same
> file. Even though, we do this synchronization before edit and before
> commit. I think that there is no way to prevent these conflicts in
> concurrent implementation. It is something that I'm not used to, since
> I'm coming from SourceSafe-like version control systems.
>
> Thanks,
> Giovanni Giazzon
>
>
> - Original Message -
> From: "Matthew Herrmann" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Monday, June 02, 2003 2:12 AM
> Subject: Re: The idea isn't clear...
>
>
>> Eclipse goes one further and gives you an opportunity to synchronise
>> in a clean area, where you can review changes that come in before they
>> are automatically merged. This is better than vanilla CVS, though it
>> is a bit slower to handle over dial-up.
>>
>> It should be called "synchronize with repository" option (or something
>> similar).
>>
>> Essentially, each user does not need to worry about the other until
>> they commit. The bigger the change, the more likely the last person to
>> commit will need to resolve conflicts with other users.
>>
>> -Original Message-
>> Date: Thu, 29 May 2003 14:54:40 -0300
>> From: "Giovanni Giazzon" <[EMAIL PROTECTED]>
>> To: <[EMAIL PROTECTED]>
>> Subject: Re: The idea isn't clear...
>> Message-ID: <[EMAIL PROTECTED]>
>> References:
>>
>>
> <[EMAIL PROTECTED]><000d01c32561$8
>> [EMAIL PROTECTED]>
>> <[EMAIL PROTECTED]>
>> Content-Type: text/plain;
>> charset="iso-8859-1"
>> MIME-Version: 1.0
>> Content-Transfer-Encoding: 7bit
>> Precedence: list
>> Message: 1
>>
>>  "you'll get a warning about being not up to date"
>>
>> That would be great, but I'm working with CVS and Eclipse and that
>> warning does not seems to exist (it's a plugin to connect to a CVS
>> server). I did some tests here with one branch being shared between
>> two developers, and without that "warning" things can get dangerous.
>> But this approach looks better than the "a branch per developer" one.
>> Does anybody have experience with CVS and Eclipse in this list?
>> Thanks,
>> Giovanni Giazzon




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

Re: The idea isn't clear...

[Matthew Herrmann]

Eclipse goes one further and gives you an opportunity to synchronise in a
clean area, where you can review changes that come in before they are
automatically merged. This is better than vanilla CVS, though it is a bit
slower to handle over dial-up.

It should be called "synchronize with repository" option (or something
similar).

Essentially, each user does not need to worry about the other until they
commit. The bigger the change, the more likely the last person to commit
will need to resolve conflicts with other users.

-Original Message-
Date: Thu, 29 May 2003 14:54:40 -0300
From: "Giovanni Giazzon" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: Re: The idea isn't clear...
Message-ID: <[EMAIL PROTECTED]>
References:

<[EMAIL PROTECTED]><000d01c32561$8
[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Content-Type: text/plain;
charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Message: 1

 "you'll get a warning about being not up to date"

That would be great, but I'm working with CVS and Eclipse and that warning
does not seems to exist (it's a plugin to connect to a CVS server). I did
some tests here with one branch being shared between two developers, and
without that "warning" things can get dangerous. But this approach looks
better than the "a branch per developer" one.
Does anybody have experience with CVS and Eclipse in this list?
Thanks,
Giovanni Giazzon





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

Meta-CVS and cmd.exe

[Matthew Herrmann]

Hi All,

Following the recent discussions on directory versioning, I'm trying out
Meta-CVS on my PC with Cygwin, possibly moving some projects to it all going
well. I can get it to talk fine through bash, but cmd.exe won't talk to it.

I've tried:

> bash mcvs

and that gives:

>bash mcvs
Meta-CVS requires a command argument.
Use mcvs -H to view help.

but

>bash mcvs -H

gives the same message. is there an easy way to get this to work?


TIA,

Matthew Herrmann
--
VB6/SQL/Java/CVS Consultancy
Far Edge Technology
http://www.faredge.com.au/



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

RE: Info-cvs Digest, Vol 5, Issue 5

[Matthew Herrmann]

To force a Makefile file to be uncommitable, but still stay more-or-less
up-to-date with the current branch, you could put this in your build script:

"
cp Makefile Makefile_
cvs up -C -rANY_FIXED_TAG Makefile
cp Makefile_ Makefile
rm Makefile_
"

Then if anyone tries to commit changes to the file, they will get an error
since they are committing to a non-sticky tag.

And of course, never use "cvs tag" to tag versions if you are using this
technique (use "cvs rtag" instead).

HTH

Matthew Herrmann
--
VB6/SQL/Java/CVS Consultancy
Far Edge Technology
http://www.faredge.com.au/

--

Date: Wed, 02 Apr 2003 10:28:08 -0800
From: Steve Madsen <[EMAIL PROTECTED]>
To: CVS-II Discussion Mailing List <[EMAIL PROTECTED]>
Subject: Re: Ignore local changes?
Message-ID: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii; format=flowed
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Message: 6

Wade Williams wrote:
> I can't imagine I'm the only developer that makes local changes to try
> something out, but wants to be sure those changes do not end up in the
> repository.

You're not the only developer that has had to deal with a problem like this.
  I agree with others who have said that allowing CVS to circumvent its own
controls is not a wise idea.

My advice is to be more specific when you commit.  You don't need to commit
from the top-level of your project.  You likely already know where you made
changes you do want to commit.  If you've arranged your tree well, this
configuration file should be somewhere else.  In this case, commit closer to
the real changes and CVS won't try to also commit your configuration
changes.

If you happen to make changes in the same place as the configuration file,
then commit files one by one.

--
Steve Madsen <[EMAIL PROTECTED]>
Tadpole Computer, Inc.  http://www.tadpole.com




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

RE: Info-cvs Digest, Vol 4, Issue 36

[Matthew Herrmann]

Brian,

If you haven't already made a large investment in BugZilla, check out
CvsTrac. We have set it up here recently, and it is very easy to configure
and use. From a user perspective, it is also a lot less overwhelming. You
also get the added bonus of its timeline which views changes chronologically
in terms of commits with drill-down.

It is pretty solid too. The only feature I would discourage use of is the
cross-referencing to check-in numbers.

http://www.cvstrac.org/

and a self-hosting demo at:
http://cvs.cvstrac.org/

Regards,

Matthew Herrmann
--
VB6/SQL/Java/CVS Consultancy
Far Edge Technology
http://www.faredge.com.au/

-Original Message-
Date: Thu, 20 Mar 2003 17:04:05 -0600
From: "Brian G. Peterson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: CVS and Bugzilla integration
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain;
charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Message: 9

I am writing to see if someone can give me some information on integrating
CVS with Bugzilla.

I've scoured the web, without success, so I'll outline what I know so far,
and hopefully someone can pick up where I leave off, and point me in the
right direction.

I've implemented the Bugzilla email gateway, which can use an email to
append to a bug report or to change the resolution of a bug.

I understand that many people use a cvs loginfo script to send a specially
formatted email or call the Bugzilla email gateway script directly.  I've
found several references to this on various lists, and even in the Bugzilla
documentation, but no links to actual code to do this.

I've looked at CVSZilla, which integrated an older version of Bugzilla and
CVS, and added a web interface on top of things, but this is too heavyweight
for my needs, and doesn't work on recent Bugzilla code anyway.

So, information from anybody about a cvs loginfo (or other) script to pass
information to Bugzilla on cvs commit information would be vastly
appreciated.

Thanks in advance,

- Brian Peterson




--

Date: Fri, 21 Mar 2003 00:11:58 -
From: "Steven Read" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: ANNOUNCEMENT: WebMets - a tool to generate software metrics from
 CVS projects
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain;
charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Reply-To: [EMAIL PROTECTED]
Message: 10

ANNOUNCEMENT: WebMets - a tool to generate software metrics from CVS
projects

_Quick Version_:

- tool to generate software metrics from a CVS project
- allows you to compare your CVS project or an anonymous access project
against others
- you can see graphs of metrics created
- please give feedback on interesting results

http://budvar.crn.cogs.susx.ac.uk/webmets/

_Longer Version_:

As part of my undergraduate dissertation at the University of Sussex in
the UK, I have created a tool to generate software metrics from CVS
repositories. This tool aims to extend typical metrics tools by using
the functions of CVS, namely the stored history of source files and
associated log files, thereby building up a picture of a development
project over time. The tool also allows the comparison of multiple CVS
projects. This is also made a lot easier because the files do not have
to be inputted, they are already stored by CVS in the repository.

In order to empirically test the tool, I have created a web site where
you can submit a repository (either your own, or an anonymously
accessible repository) for processing and compare it to other
repositories. You get to see pretty graphs of the metrics of your
project and gauge your software development versus other teams. It's
interesting and also rather good fun!

The aim of the web site is to collect feedback from developers/others
about interesting results generated and results that illustrate good use
of the tool. I would be very grateful for any feedback that you may
have.

The address of WebMets, the web based version of the tool is:
http://budvar.crn.cogs.susx.ac.uk/webmets/

Please submit your feedback via the web site or directly to me:
[EMAIL PROTECTED]

Thank you in advance for your time and please forward this message to
others who may be interested,

Steven Read.
---
3rd Year Finalist - Computer Science with Management Studies,
School of Cognitive and Computing Science,
University of Sussex,
Brighton, UK.
[EMAIL PROTECTED]




--

Date: Fri, 21 Mar 2003 09:45:37 +0530
From: "Sumit Ranjan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: unsubscribe me please
Message-ID: <[EMAIL PROTECTED]>
Content-Type: multipart/alternative;
boundary="=_NextPart_000_0034_01C2EF8E.A0A9EB00&qu

Re: Branch Merging Behaviour

[Matthew Herrmann]

Hi Mark,

A merge doesn't care where it is from a branch to a branch, or a branch to a
trunk... it is just applying a set of diffs to files.

To troubleshoot, it's best to think in terms of an individual file, not a
whole module.

In the case of removing a file that was on the branch, you should have:

file1.c   1.1state: alivetag: BRANCHHEAD
file1.c   1.1.2.1state: dead tag: BRANCH

then when you merge this changes between BRANCHHEAD and BRANCH, then this
becomes the change between revision 1.1 and 1.1.2.1 on file1.c, that is, the
state changing to "dead".

What should happen is that whenever, in any working directory, on any
branch:
- file1.c has state "alive" (i think they call it "exp")
- calling the function "cvs up -j1.1 -j1.1.2.1 file1.c" causes "cvs rm -f
file1.c" to be invoked on the working directory.

If this doesn't happen, then you have a clear bug.

There has been lots of confusion (and I think bugs also ) with relation to
handling of the Attic directory in CVS, which handles files which do not
exist on the trunk. This would be the first place to look.

If you do a search for removing files and "attic", you will probably pick up
a whole spate of people's previous problems.

To solve the problem, I recommend you:

- try out a simple example with exactly one file on a local repository,
adding and removing it from branches, etc. and then email the list with a
transcript of your instructions, and the output of the "cvs log" function.
- report your cvs client and server versions. bugs such as the one you
mention tend to be picked up from time to time and fixed. I have a very
recent version which fixed a bug I found in branch-of-branch handling when
giving log output. This means there is a good chance your bug is fixed on a
new version.

HTH,

Matthew Herrmann
--
Far Edge Technology
http://www.faredge.com.au/

-Original Message-

Date: Wed, 19 Mar 2003 17:11:40 +
From: "Mark Cooper" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Branch Merging Behaviour

...

We have recently noticed a difference in the way that a merge works
between two branches and between a branch and the main trunk.

Consider the following:
branch taken from trunk
work proceeds
some files removed from trunk (head)
new branch taken from trunk
working copy updated to new branch
first branch merged into new branch

What appears to be happening under this scenario is that the files that
were removed from the trunk but which still exist in the early branch are
re-added into the new branch, then when in its turn the new branch is
merged back into the trunk, the files are re-added to the trunk. This has
caused us a couple of headaches wondering why removed files kept
mysteriously re-appearing on the trunk.

This does not occur when doing a merge of a branch into a working copy of
the the trunk (head revisions).

Is this behaviour correct?

I've searched through previous mailing list archives and issue/bug
reports, but can't find any reference to this. The manual is particularly
obscure about the subject.

Mark Cooper
Reuse Manager
Microlise Limited
http://www.microlise.co.uk
mailto:[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


End of Info-cvs Digest, Vol 4, Issue 34
***



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

RE: Info-cvs Digest, Vol 3, Issue 42

[Matthew Herrmann]

Hi Doug,

> Yes, that is what I am saying.  We have a multi-platform build
> environment here. There are basic three phases:

Okay, I assume this is for creating builds, and not part of your day-to-day
work. Ie. build ~= release /= coding

> Then what is the point of the cvswrappers MERGE directive?  Clearly,
> if diff can be told to try to diff two binary files, then CVS
> should be able to diff two files marked -kb if the MERGE directive
> so stipulates.

No idea re the MERGE directive. But what you want exceeds the diff features
available in CVS. GNU Diff can be told to diff binary files, but all you
will get is "files are different" or "files are the same". Diff3 has no
capacity for binary diffs, so it cannot make sense of the files. Your only
bet would be to 'trick' diff3 into momentarily forgetting that you have told
it they were binary files. But this is going down a deep rabbit hole.

Given that your build/release process is a one-way process (and so it's more
an export from CVS instead of a checkout), i really do believe your best
option is then to include a unix2dos command just before you build the vb
source.

> And sure, I could also checkout on Windows-- but that too is like
> the tail wagging the dog from a multi-platform build env.
Do you cvs commit, cvs diff, etc. all from your Unix machine, or from a
windows box when you work on the vb code? I assume you have a separate copy
of cvs running there for the day-to-day development and you don't copy your
code back to a unix pc to commit it.

In this case, you may as well do your everyday work in an environment that
VB is comfortable with.

So, further understanding the problem I would suggest:
1. Change all vb frm, cls, mdl, source files to -kkv (text mode)
2. Use CVS on your windows box to check out code in CRLF mode while you
develop
3. Add a step to your release process just before it compiles the VB code to
change the line ending to CRLF.

I don't think you can dispute that this will make your day-to-day
development easier, and will not impact on your build process, plus CVS is
being used more in the manner "they" intended. (which has no merit except
that things tend to work better when it is).

> The fix should, IMHO, be applied to the server. Maybe this feature
> (cvswrappers MERGE directive) is what CVS developers had intended
> to do, but have not yet fully implemented. I wish some of them
> would kindly speak up. :-)

I doubt it. From my reading of this newsgroup, I think you would get the
response that:
 - text modes (LF vs CRLF) should not be crossed between platforms, and cvs
should not be forced to do it (so WinCVS gets a big cross)
 - -kb should only be used for truly binary files, and then sparingly (Greg
Woods in particular, and many others grudgingly)

HTH,

Matt

-Original Message-
From: Douglas Finkle [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 26 February 2003 04:37
To: 'Matthew Herrmann'; info-cvs (E-mail)
Subject: RE: Info-cvs Digest, Vol 3, Issue 42


Matt, thanks for your response.

> are you saying that they must be checked out to unix format,
> even on windows machines? then how does Visual Basic compile
> the source code, since it expects it in CRLF format?

Yes, that is what I am saying.  We have a multi-platform build
environment here. There are basic three phases:
1. code check out on a master platform (is UNIX)
2. do platform independent stuff
3. build platform-specific code (Solaris, HPUX, Windows, etc.)

>From a process perspective it makes sense to have the code checkout
occur on one machine, from a single repository.

But in order for VB, etc. stuff to build the sources need to be
-kb'ed which is much less than optimal for ASCII (mergable) files.

> -kb is used to tell cvs not to presume to know what an
> end-of-line character should look like. you cannot have this
> and also do (line-based) merges, since it doesn't know what the
> end of a line is!

Then what is the point of the cvswrappers MERGE directive?  Clearly,
if diff can be told to try to diff two binary files, then CVS
should be able to diff two files marked -kb if the MERGE directive
so stipulates.

I can, if necessary, create make rules that use the Cygwin toolset
to apply unix2dos, and then again do something similar in a
commitinfo hook.  Possible, but messy.

And sure, I could also checkout on Windows-- but that too is like
the tail wagging the dog from a multi-platform build env.

The fix should, IMHO, be applied to the server. Maybe this feature
(cvswrappers MERGE directive) is what CVS developers had intended
to do, but have not yet fully implemented. I wish some of them
would kindly speak up. :-)



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

RE: Info-cvs Digest, Vol 3, Issue 42

[Matthew Herrmann]

are you saying that they must be checked out to unix format, even on windows
machines? then how does Visual Basic compile the source code, since it
expects it in CRLF format?

-kb is used to tell cvs not to presume to know what an end-of-line character
should look like. you cannot have this and also do (line-based) merges,
since it doesn't know what the end of a line is!

your best bet, short of checking out in windows format, is to actively
subvert your build process. First, re-save your visual basic scripts as
mergeable text with the -kk (default) setting. You will then get mergeable
(but unix terminated) text when you check out. Create a script which
converts checked out vb files to have windows line endings, before you
compile or edit them. Then, before you check them in again, you'll need to
make another script which converts them back to unix format. Sounds
complicated? It is.

This is because this is intentionally avoiding a useful feature of CVS which
is to convert line endings automatically for you to your target platform. I
would have a chat to the people writing the build scripts since this seems a
bit like the tail wagging the dog. Alternatively, if you're developing in
VB, just set up your environment to check in/check out in Windows format,
and other unix developers can happily check in/check out in Unix format, and
noone will be the wiser to the platform anyone used to do their work.

Anyway, this batch file converts from unix to windows format if you decide
to go the hard way:

@echo off
sed "s/\(.*\)/\1/" %1 > %TEMP%\~2389234.tmp
cp %TEMP%\~2389234.tmp %1
====

HTH,

Matthew Herrmann
--
Far Edge Technology

-Original Message-
Date: Mon, 24 Feb 2003 17:36:52 -0500
From: Douglas Finkle <[EMAIL PROTECTED]>
To: "info-cvs (E-mail)" <[EMAIL PROTECTED]>
Subject: Problems with cvswrappers MERGE directive
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain;
charset="iso-8859-1"
MIME-Version: 1.0
Precedence: list
Message: 11

I need to be able to provide the CVS server with a directive
that forces a merge using the cvswrappers functionality,
overriding CVS's default COPY behavior for files marked as '-kb'.

Without adding complications of explaining our build process
suffice it to say there is a requirement that all sources,
regardless of the platform on which they build/run, are
checked out on UNIX. This of course causes all files to have
UNIX line endings-- unless the files are -kbe'ed, in which
case line endings are untouched.

The lack of a CR/LF line ending format cause file read errors
by IDE's such as MS VB-- unless line endings are preserved by
way of marking the files as binary, i.e. '-kb'. But then there
is no merge-- only copy.

What I really need, since many of the IDE files are truly
ascii text, is to using the MERGE directive to *force* the
merge of the selected files.

Here is an example of what I have in cvswrappers:

# Visual Basic Formats
*.[Cc][Ll][Ss] -k 'b' -m 'MERGE'

But, the MERGE directive is being ignored, and a COPY is
instead occurring. I really need this flexibility... hopefully
I am just doing something wrong, or maybe a later version
of the server will do.

Presently using CVS 1.11.1p1 on Solaris 2.8.  Thanks!!!



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

cvsignore to ignore subdirectories instead of files?

[Matthew Herrmann]

hi all,

I have a project which produces HTML output into a subfolder called "HTML".
I want to ignore the folder because I produce it with my build script.

However, .cvsignore only ignores files. Any way around this?

TIA,

Matthew Herrmann
--
Far Edge Technology



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

RE: Info-cvs Digest, Vol 3, Issue 36

[Matthew Herrmann]

Just do "cvs up" twice. The first time you'll get all the updates and
messages whizzing by, the second time, only the conflicts and your changes
will show up.

HTH

-Original Message-
Date: 21 Feb 2003 07:55:55 -0500
From: Steven Tryon <[EMAIL PROTECTED]>
To: richard blair <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: cvs update info
Message-ID: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Content-Type: text/plain
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Message: 8

Rich,

cvs update >update.txt ?
cvs update | less ?

Steve

On Thu, 2003-02-20 at 18:57, richard blair wrote:
> I perform a cvs update on a large directory structure, and a conflict
> happens, but the file it happened on is too far up to scroll to.  Does
> anyone know how to retrieve that information? In other words, how do I
> find out which files were in conflict after I have performed an update?
>
> Rich

--
Steven Tryon, CIBER @ Xerox
Webmaster, Xerox Global Service Net
8*221-7719 / 585-231-7719



--

Date: Fri, 21 Feb 2003 05:19:34 -0800 (PST)
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: cvs update info
Message-ID: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Content-Type: multipart/mixed; boundary="=_20030221051934_32271"
MIME-Version: 1.0
Precedence: list
Message: 9

--=_20030221051934_32271
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Try using the attached perl script.  It cleans up the display quite
nicely, with a summary at the end for things like conflicts, files in the
way, etc.

> I perform a cvs update on a large directory structure, and a conflict
> happens, but the file it happened on is too far up to scroll to.  Does
> anyone know how to retrieve that information? In other words, how do I
> find out which files were in conflict after I have performed an update?
>
> Rich
>
>
>
> ___
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/info-cvs



--=_20030221051934_32271
Content-Type: application/octet-stream; name="cvs_update_display.pl"
Content-Disposition: attachment; filename="cvs_update_display.pl"
Content-Transfer-Encoding: base64

IyEvdXNyL2xvY2FsL2Jpbi9wZXJsCiMgLyo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CiMgPT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSov
CgogICBAbG9jYWxtb2QgPSAoKTsKICAgQGxvY2FsYWRkID0gKCk7CiAgIEBjb25mbGljdHMgPSAo
KTsKICAgQG1vdmVhd2F5ID0gKCk7CiAgIEBlcnJvcnMgPSAoKTsKICAgd2hpbGUoPD4pIHsKICAg
ICAgaWYgKCAvXlUgKC4rKS8gKSB7CiAgICAgICAgICRuYW1lID0gJDE7CiAgICAgICAgIHByaW50
ICJVcGRhdGluZyAkbmFtZVxuIjsKICAgICAgfSBlbHNpZiAoL15QICguKykvICkgewogICAgICAg
ICAkbmFtZSA9ICQxOwogICAgICAgICBwcmludCAiVXBkYXRpbmcgJG5hbWVcbiI7CiAgICAgIH0g
ZWxzaWYgKC9eTWVyZ2luZyAoLispLyApIHsKICAgICAgICAgd2hpbGUoPD4pIHsKICAgICAgICAg
ICAgaWYgKC9eTSAoLispLyApIHsKICAgICAgICAgICAgICAgJG5hbWUgPSAkMTsKICAgICAgICAg
ICAgICAgcHJpbnQgIlVwZGF0aW5nICRuYW1lXG4iOwogICAgICAgICAgICAgICBsYXN0OwogICAg
ICAgICAgICB9IGVsc2lmICgvXkMgKC4rKS8gKSB7CiAgICAgICAgICAgICAgICRuYW1lID0gJDE7
CiAgICAgICAgICAgICAgIHByaW50ICJVcGRhdGluZyAkbmFtZVxuIjsKICAgICAgICAgICAgICAg
cHVzaCBAY29uZmxpY3RzLCAkbmFtZTsKICAgICAgICAgICAgICAgbGFzdDsKICAgICAgICAgICAg
fQogICAgICAgICB9CiAgICAgIH0gZWxzaWYgKC9eTSAoLispLyApIHsKICAgICAgICAgJG5hbWUg
PSAkMTsKICAgICAgICAgcHVzaCBAbG9jYWxtb2QsICRuYW1lOwogICAgICB9IGVsc2lmICgvXkMg
KC4rKS8gKSB7CiAgICAgICAgICRuYW1lID0gJDE7CiAgICAgICAgIHByaW50ICJVcGRhdGluZyAk
bmFtZVxuIjsKICAgICAgICAgcHVzaCBAY29uZmxpY3RzLCAkbmFtZTsKICAgICAgfSBlbHNpZiAo
L15BICguKykvICkgewogICAgICAgICAkbmFtZSA9ICQxOwogICAgICAgICBwdXNoIEBsb2NhbGFk
ZCwgJG5hbWU7CiAgICAgIH0gZWxzaWYgKC9eY3ZzIHVwZGF0ZTogbW92ZSBhd2F5IChbXjtdKyk7
LykgewogICAgICAgICAkbmFtZSA9ICQxOwogICAgICAgICBwdXNoIEBtb3ZlYXdheSwgJG5hbWU7
CiAgICAgICAgICRuZXh0bGluZSA9IDw+OwogICAgICB9IGVsc2lmICgvXmN2cyB1cGRhdGU6IChb
XlxzXSspIGlzIG5vIGxvbmdlciBpbiB0aGUgcmVwb3NpdG9yeS8pIHsKICAgICAgICAgJG5hbWUg
PSAkMTsKICAgICAgICAgcHJpbnQgIkRlbGV0aW5nOiAkbmFtZVxuIjsKICAgICAgfSBlbHNpZiAo
L15jdnMgXFt1cGRhdGUgYWJvcnRlZFxdOiAoLispLyApIHsKICAgICAgICAgJG1lc3NhZ2UgPSAk
MTsKICAgICAgICAgcHVzaCBAZXJyb3JzLCAkbWVzc2FnZTsKICAgICAgfSBlbHNpZiAoL3dhaXRp
bmcgZm9yLykgewogICAgICAgICBwcmludCAkXzsKICAgICAgfQogICB9CiAgIGlmKCAkI2NvbmZs
aWN0cyA+IC0xICkgewogICAgICB1bnNoaWZ0IEBjb25mbGljdHMsICJUaGUgZm9sbG93aW5nIGZp
bGVzIGhhZCBtZXJnZSBjb25mbGljdHM6IjsKICAgICAgcHJpbnQgam9pbigiXG4gLS0tICIsQGNv
bmZsaWN0cyk7CiAgICAgIHByaW50ICJcbiI7CiAgIH0KICAgaWYoICQjY29uZmxpY3RzID4gLTEg
JiYgJCNtb3ZlYXdheSA+IC0xKSB7CiAgICAgIHByaW50ICJcbiI7CiAgIH0KICAgaWYoICQjbW92
ZWF3YXkgPiAtMSApIHsKICAgICAgdW5zaGlmdCBAbW92ZWF3YXksICJUaGUgZm9sbG93aW5nIGZp
bGVzIGFyZSBpbiB0aGUgd2F5OiI7CiAgICAgIHByaW50IGpvaW4oIlxuIC0tLSAiLEBtb3ZlYXdh
eSk7CiAgICAgIHByaW50ICJcbiI7CiAgIH0KICAgaWYoICQjbW92ZWF3YXkgPiAtMSAmJiAkI2Vy
cm9ycyA+IC0xKSB7Ci

RE: Info-cvs Digest, Vol 3, Issue 29

[Matthew Herrmann]

Hongbiao,

This is a CVS newsgroup, not a cygwin newsgroup. Please use google news to
search
for your problem first, and you will probably find many messages from a
group like
"comp.cygwin.gcc" coming up or similar. Put your message to this newsgroup
instead.

-- matthew

-Original Message-

Date: Mon, 17 Feb 2003 10:23:04 -
From: "Dong, Hongbiao" <[EMAIL PROTECTED]>
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
Subject: Help Required for link files automatically
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain;
charset="ISO-8859-1"
MIME-Version: 1.0
Precedence: list
Message: 2


Hello All,

When I try to compile any program under the Cygwin shell with the GCC
compiler, I get the error

crt0.o not found

despite this file being available in /usr/lib or /usr/bin; which are in the
system path. A pass-by solution for this problem is to copy the file and all
other files named crt*.o from /usr/bin and /usr/lib into the object
directory before compiling. This is not a perfect solution, ang suggestion
for how to link these files automatically will be a big help.

Pls suggest.

Regrads,
Hongbiao




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

RE: Info-cvs Digest, Vol 3, Issue 6

[Matthew Herrmann]

Marc,

Check the "cvs history" command. It can tell you the date that tags were
applied.

Cheers,
Matt



Date: Tue, 4 Feb 2003 11:37:24 -0500
From: "Marc Tessier" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: Extracting multiple TAG at the same time
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain;
charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Precedence: list
Message: 8

Hi everyone

I am wandering if there is any options to extract the most recent =
version of a list of TAG? I have tag A, B, C  and the I want to get the =
most recent files of all three in one cvs checkout or cvs export so I =
don't have to check the files version one by one.=20

thanks

Marc



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

Re: connection using pserver

[Matthew Herrmann]

Hi Kenneth,

We're using pserver with Windows 2000 and CVSNT, connecting to multiple
repositories using a little tool which sets the CVS environment variables
for the command prompt. We go through an SSH tunnel, so the pserver
insecurity is mitigated, although it is still possible if you don't log off
for someone to find a passwd file on your computer.

This setup, however, has worked very well for us. Using Putty for tunneling
is more reliable than PLink.exe, which breaks the connection if you press
CTRL-C to interrupt a CVS operation.

We don't use :ext: since that would require typing in my passphrase for
every commit with my current ssh key setup. I would love to hear of a way to
set this up, apparently there are some keyring programs, but they're more
for linux.

By the way, there is no need to use Cygwin to run CVS under Windows. I ran
CVS built under NT for quite a while, and recently moved to CVSNT. You could
get line conversion issues if you don't set Cygwin correctly, whereas CVSNT
always checks out files with windows CR-LF endings.


cheers,

Matthew Herrmann

-Original Message-
Date: Fri, 17 Jan 2003 14:00:01 -0800
From: Kenneth Porter <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: connection using pserver
Message-ID: <2527436090.1042812001@[10.69.3.69]>
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Message: 10

--On Friday, January 17, 2003 4:46 PM -0500 Larry Jones
<[EMAIL PROTECTED]> wrote:

> If you're at all concerned about security, you should
> not be using pserver, you should be using :ext: with SSH.

We started down this path but couldn't get it working on Windows with
cygwin ssh. (Server is a Red Hat box, though.) Is there a cookbook
somewhere that explains how to make that scenario work?

For other tunneling (eg. X) I've been using the latest PuTTY, which seems
to work pretty well. Has anyone set up a Windows CVS client using PuTTY?




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

Re: How is a patch applied to CVS?

[Matthew Herrmann]

Hi,

But can patch be run in such a way that it generates conflict markers
instead of .rej files? This would be very useful at times. Or is diff3 the
go here instead?

cheers,
matt

-Original Message-
Date: Tue, 7 Jan 2003 17:03:15 -0500
From: Eric Siegerman <[EMAIL PROTECTED]>
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
Subject: Re: How is a patch applied to CVS?
Message-ID: <[EMAIL PROTECTED]>
In-Reply-To:
<[EMAIL PROTECTED]>;
from[EMAIL PROTECTED] on Mon, Jan 06, 2003 at 08:23:52PM -0500
References:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Precedence: list
Message: 9

On Mon, Jan 06, 2003 at 08:23:52PM -0500, Mazza, Glen R., ,CPMS wrote:
> How is a patch file committed into CVS to update
> the most recent version?

In several steps:
  - Apply the patch to a checked-out working directory
  - Resolve any conflicts (i.e. .rej files)
  - Compile and test
  - "cvs commit"

CVS itself can't digest arbitrary patch files.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
Just Say No to the "faceless cannonfodder" stereotype.
- http://www.ainurin.net/ (an Orc site)


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, 8 January 2003 14:44
To: [EMAIL PROTECTED]
Subject: Info-cvs Digest, Vol 2, Issue 11


Send Info-cvs mailing list submissions to
[EMAIL PROTECTED]

To subscribe or unsubscribe via the World Wide Web, visit
http://mail.gnu.org/mailman/listinfo/info-cvs
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]

You can reach the person managing the list at
[EMAIL PROTECTED]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Info-cvs digest..."


Today's Topics:

   1. RE: cvs hangs while reporting 'version' (SOLVED) (Harig, Mark A.)
   2. Docs for cvs 1.11.4 (Douglas Finkle)
   3. Re: How is a patch applied to CVS? (Kaz Kylheku)
   4. FW: CVS Multiple checkouts prevent.. (Mariappan Muthiah)
   5. Re: How is a patch applied to CVS? (Riechers, Matthew W)
   6. Re: CVS and multiple platforms - version conflicts,
  featuresavailable
etc.
   7. Re: CVS and multiple platforms - version conflicts, features
available (Larry Jones)
   8. Re: CVS and multiple platforms - version conflicts, features
   available etc. (ADFH)
   9. Re: How is a patch applied to CVS? (Eric Siegerman)


--

Date: Tue, 7 Jan 2003 14:11:01 -0500
From: "Harig, Mark A." <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: RE: cvs hangs while reporting 'version' (SOLVED)
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain;
charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Precedence: list
Message: 1

> -Original Message-
> From: Larry Jones [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 04, 2003 5:27 PM
> To: Harig, Mark A.
> Cc: [EMAIL PROTECTED]
> Subject: Re: cvs hangs while reporting 'version'
>=20
>=20
> Harig, Mark A. writes:
> >=20
> > The above is NOT a typo.  After 'read(5,', the output hangs with the
> > cursor
> > following the '5,'.  I have left this run for nearly thirty=20
> minutes to
> > see
> > if there was a timeout condition, before using 'Ctrl-C' to halt the
> > command.
>=20
> Try upgrading to the recently-released CVS 1.11.4.
>=20
> -Larry Jones
>=20

Thanks for the suggestion.  I upgraded my CVS client to 1.11.4.  cvs
still
hangs, but at a different place -- during a call to wait():

$ export CVS_RSH=3D/usr/bin/ssh
$ strace cvs -t -f -d:/path/to/cvs/repos version

(much text omitted)

write(4, "UseUnchanged\n", 13)  =3D 13
write(4, "Global_option -t\nversion\n", 25) =3D 25
read(5, "M ", 4096) =3D 2
read(5, "Concurrent Versions System (CVS)"..., 4096) =3D 58
write(1, "Server: Concurrent Versions Syst"..., 66Server: Concurrent
Versions System (CVS) 1.11.1p1 (client/server)
) =3D 66
read(5, "ok\n", 4096)   =3D 3
fstat64(4, {st_mode=3DS_IFIFO|0600, st_size=3D0, ...}) =3D 0
close(4)=3D 0
munmap(0x40018000, 4096)=3D 0
fstat64(5, {st_mode=3DS_IFIFO|0600, st_size=3D0, ...}) =3D 0
close(5)=3D 0
munmap(0x40019000, 4096)=3D 0
wait4(7090,=20

Because my ssh connection has been working seemlessly between
the client and server machines, I did not suspect that it
could be the cause of the problem.  Nevertheless, I checked
the versions of openssh that I was running on the client
and the server.  Because they were different, I upgraded
the version I am running on the client machine to match
the version that I am running on the server machine.

This solved the problem.  cvs now works regardless of
whether I use cvs 1.11.4 or cvs 1.11.1p1 as the client.

For future refer

HTML Patch Log available to roll back, diff for commits

[Matthew Herrmann]

Hi Everyone,

I've finished a preliminary version of the HTMLChangeLog stylesheet.

It is quite powerful, and fills in some pretty important holes in
functionality in CVS on its own.

You can feed it the output of
"changelog --xml" to get a pretty output with patch commands.

Download the stylesheet at:
http://www.matt.faredge.com.au/HTMLChangeLog.xsl

Features:
- no need to change your current client, it's just a stylesheet, not an app
you have to install
- multi-platform (not yet :<, since the previousRevision is done in JScript)
- roll back commits
- roll forward commits into other branches to incorporate features from dev
version into production, for example
- view diffs of any commit for QC, code review.
- really easy to code and hence extend (the file is only 8k, and it's really
basic xsl)

TODO:
- change snippet of Jscript code to XSL code
- handle tagging a patch (not as easy as you think! what about the other
files...)
- replace \n\n with  in output text, to match formatting of changelog
output in text format.

Please let me know what you think, and send me patches of any changes you
make for your own dev so i can incorporate them into the main version and
others can benefit (your credits included).

Regards,

Matthew Herrmann
--
http://www.faredge.com.au/
Far Edge Technology
Level 11, 80 Mount St
North Sydney NSW 2060
Australia



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

RE: My own substitution keywords

[Matthew Herrmann]

Hi Fredrik,

My advice is to check out the scripts you can run on the server side
on commit. You can only allow commits of *.java files which contain
the copyright text.

You can then include the code template in the project in a /resources
folder so people will at first try to commit a vanilla code file, get
an error, then they will get into the habit of starting with the
template.

Only problem with this is that the copyright message is hard to change.
If you are publishing your code, just add a little script to the end of
it, and have people run release.sh which exports and adds copyright
messages, (version controlled in your project folder), instead of typing
"cvs export". This will get you the closest to the behaviour you are after.

To release software here, we have a "release.bat" which checks out a tagged
version, then checks it for style errors, etc.

cheers,
matt


>>>
Date: Mon, 30 Dec 2002 13:26:31 +0100
From: Fredrik Wendt <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: My own substitution keywords
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii; format=flowed
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Message: 1

Hi all.

I just wondered if there's a way to define my own keywords. I guess this
is somewhat hardcoded into cvs, but what alternatives are there to for
example insert a standard copyright message into source files?

Thanks,

Fredrik



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

using cvs2cl xml output to extend cvs functionality

[Matthew Herrmann]

hi everyone,

just thought i'd let people know, i'm doing some work on a definitive
solution to the whole "cvs doesn't handle rolling back commits easily", "cvs
can't tag files with the same log message", etc. problem.

here's the idea:

step 1) cvs2cl --xml generates XML output
step 2) XSLT stylesheet converts changelog to cvs scripts for performing
basic operations, like cvs up -jr1 -jr2.

The output is a DHTML page where you can click on + signs to view
information about commits.

...
[+] Fixed Bug
_CVS Commands To Rollback This Commit_
_CVS Commands To View Changed Lines In This Commit_
...

[+] Fixed Bug
_CVS Commands To Rollback This Commit_
_CVS Commands To View Changed Lines In This Commit_
 cvs diff -r1.23.1.28 -r1.23.1.29 file1.c
 cvs diff -r1.6 -r6.1.1 file2.c
 ...

copy the cvs diff commands into your workspace and run!

The approach will work spot-on for rolling back commits. In this case, just
a whole series of cvs up -j messages are produced.

The beauty of the approach is:
- extensible
- cross-platform
- most of the hard work is done already by cvs2cl
- easy... i hope!

What do people think?

Regards,

Matthew Herrmann
--
Far Edge Technology
Level 11, 80 Mount St
North Sydney NSW 2060
Australia

Ph: 02 9955 3640
Mob: 0404 852 537



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

Re: CVSROOT must be an absolute pathname problem

[Matthew Herrmann]

Hi Mark,

I'd advise to just use the CVSNT.exe file instead. It's dump-in-a-folder
installable, and much more windows friendly -- for example, all the
repository settings can be specified in the registry instead of environment
variables (which are a total pain to modify globally in 98 _and_ 2000). Plus
you will never run into the CR-LF line termination issues that people
sometimes get with cygwin CVS when they choose the wrong setting.

It also has some little things like using "cvs pass" will bring up asterixes
as you type.

cheers,
matt

-Original Message-

Thank-you. After resetting CVSROOT
(CVSROOT=:local:/cygdrive/c/cygwin/home/Mark/src/master), cvs init returned
the following:

cvs init: syntax error in
/cygdrive/c/cygwin/home/Mark/src/master/CVSROOT/config' is missing '='

Subsequent cvs init's from c:/ runs without error - but ONLY in c:/

Performing a cvs init or any other cvs command from any other directory
continues to render:

GANDALF:/cygdrive/c/ensignInternet> cvs up
cvs update: CVSROOT must be an absolute pathname (not
`c:\cygwin\home\Mark\src\m')ter
cvs update: when using local access method.
'.s [update aborted]: Bad CVSROOT: `:local:c:\cygwin\home\Mark\src\master

I am not sure why the "ter" shows up following the close paren above. And
the .s is confusing as well.

Mark.

-Original Message-
From: Larry Jones [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 13, 2002 9:35 AM
To: Mark Scoville
Cc: [EMAIL PROTECTED]
Subject: Re: CVSROOT must be an absolute pathname problem

Mark Scoville writes:
>
> GANDALF:/cygdrive/c> cvs init
> cvs init: CVSROOT must be an absolute pathname (not
> `c:/cygwin/home/Mark/src/master')
> cvs init: when using local access method.
> cvs [init aborted]: Bad CVSROOT: `:local:c:/cygwin/home/Mark/src/master'.

Try using ":local:/cygdrive/c/cygwin/home/Mark/src/master" instead.

-Larry Jones

I don't need to do a better job.  I need better P.R. on the job I DO.
-- Calvin



--

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


End of Info-cvs Digest, Vol 1, Issue 2132
*



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

RE: first change on a branch causes no change to show up in -rTAGA::TAGB

[Matthew Herrmann]

Hi Everyone,

This is to let you know that I have just tried out the development version
of cvs post Larry's latest fix to log.c, and i'm now getting spot-on
tag-to-tag version histories using cvs2cl, including when the tags are on
branches.

So it gets the big thumbs up from me!

Thanks Larry.

Cheers,
matt

-Original Message-
From: Larry Jones [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 20 November 2002 04:57
To: Matthew Herrmann
Cc: [EMAIL PROTECTED]
Subject: Re: first change on a branch causes no change to show up in
-rTAGA::TAGB


Matthew Herrmann writes:
>
> I have taken Larry's suggestion and installed the latest dev version and
it
> is better, but still not 100%.

I've just checked in a new revision of log.c that I think fixes the
problem.  Let me know how it works.

-Larry Jones

The real fun of living wisely is that you get to be smug about it. -- Hobbes



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

RE: first change on a branch causes no change to show up in -rTAGA::TAGB

[Matthew Herrmann]

Hi All,

I have taken Larry's suggestion and installed the latest dev version and it
is better, but still not 100%.

Here is the problem I found on development version of CVS:

For a file, FILE1:

Tags:

=
TAG2: 1.3.2.1
TAG1: 1.3
TAG2_BRANCH: 1.3.2.1.0.2

Revisions:

=
revision 1.3
date: 2001/12/16 23:13:12;  author: matthew;  state: Exp;  lines: +1 -1
branches:  1.3.2;
...

-
revision 1.3.2.1
date: 2002/10/17 23:36:14;  author: matthew;  state: Exp;  lines: +1 -1
...

=

the revision 1.3.2.1.0.2 doesn't exist, i'm guessing because it is a magic
branch tag. anyway, that seemed a little weird to me because all my other
tags, even
branch tags are always on a physical tag (or so I thought).

doing:

cvs log -rTAG1::TAG2 should produce log info for 1.3.2.1, but it produces
info
for 1.3 instead.

The interesting thing is that 1.3.2.1 is the start of another
branch which was a branch off our production branch for a minor bug-fix. So
I think this is the case that is not handled.

I have got some other extraneous changes but I think they are very likely
due to
this same problem.

cheers,
matt

Matthew Herrmann wrote:
>
> Hi All,
>
> I'm using cvs2cl to generate version differences on branches, but I'm
having
> trouble with picking up changes where no change was previously there. I
> think the problem is one in cvs log, though, not cvs2cl.
>
> Here's the command I use
>
> cvs2cl -w -f ChangeLog_%1_To_%2.txt -r%1::%2
>
> the scenario that breaks it is:
>
> working on branch BRANCH1
>
> at TAG1, on BRANCH1 : file is on 1.23
> at TAG2, on BRANCH1 file is on 1.23.1.4 after changes
>
> the problem is that even when looking at 2 tags on the same branch, it is
> only after the first change to the file that it becomes _really_ on the
> branch, before that, the tag is still officially on the trunk.
>
> What would fix this for me is for 1.23 => 1.23.x.y to be considered on the
> same line. At the moment the line is only being start just after 1.23
which
> means I'm losing a significant number of changes out of these history
logs.
>
> are there any patches available for this problem? some others must have
had
> this problem with log -r.
>
> cheers,
> matt
I assume you are speaking of either
http://search.cpan.org/author/FLUFFY/CVSUtils-1.00/
or http://www.red-bean.com/cvs2cl/

the '-r' option to cvs2cl is for:
[-r, --revisions  Show revision numbers in output]

what I think you want is to pass options to cvs log so you should use -l
"options":
[-l OPTS, --log-opts OPTS Invoke like this "cvs ... log OPTS"]

if you want to pass revisions to cvs log I believe it should be something
like

cvs2cl -l "-r%1::%2" -w -f ChangeLog_%1_To_%2.txt

I use the global compress option as
cvs2cl.pl -g "-z9" -r -t -f cl.txt
so I think the line I gave you above will work, if cvs log will accept
whatever
"-r%1::%2" evaluates to.

--
I'd crawl over an acre of 'Visual This++' and 'Integrated Development
That' to get to gcc, Emacs, and gdb.  Thank you.
-- Vance Petree, Virginia Power



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

RE: first change on a branch causes no change to show up in -rTAGA::TAGB

[Matthew Herrmann]

Thanks todd, but with this option I see the exact behaviour.

The problem, as I verified is that the -rTAG1::TAG2 option
will not output any revisions when TAG1 and TAG2 are not "on the same
branch".

cvs log -rBRANCHTAG1::BRANCHTAG2 main\Main.bas

What is frustrating about this is that these tags _are_ on the same branch,
but that it is only after the first commit that the revision number moves
from being a trunk revision number to a branch revision number.

Ie. BRANCHTAG1 was taken before I made any changes to the file on the
branch, and BRANCHTAG2 was taken after I made some changes to it.

This effectively nullifies the use of cvs2cl in this manner or -rTAG1::TAG2,
unless one makes a dummy commit to every single file to force it to
'really' be on the branch, when one starts one. I personally find this a
pretty
messy workaround, especially since I can't apply it retrospectively.

The other alternative would be to say that, for a given revision

"X1.X2.X3. ... .Xn"

(ie. 1.52.1.20)

the file:

"X1.X2.X3. ... .Qn"

(ie. 1.52.1.13)

is on the branch (current behaviour), and so is

the file:

"X1.X2.X3. ... .X(n-2)"

(ie. 1.52)

and is before all revisions from "X1.X2.X3. ... .1" to "X1.X2.X3. ...
.infinity"

Are there any philosophical problems with this approach? I don't know of too
many people who fiddle with revision numbers, and even less who fiddle with
branch numbers.

I think the likelihood of someone branching off 1.52 and renumbering the
branch 1.53.1.2 extremely unlikely. In my reading of the Cederqvist,
renumbering the
branch in this way would actually go against what "branching of a file is"
actually means.

Intuitively, 1.53 is the parent of the branch 1.53.xx.yy.

What do other people think? Does anyone know a workable workaround, or know
of
a patch for this?

cheers,
matt

-Original Message-
From: [EMAIL PROTECTED]
[mailto:tdennist@;glock.ssa.crane.navy.mil]On Behalf Of Todd Denniston
Sent: Thursday, 14 November 2002 01:10
To: Matthew Herrmann
Cc: CVS Mailing List
Subject: Re: first change on a branch causes no change to show up in
-rTAGA::TAGB


Matthew Herrmann wrote:
>
> Hi All,
>
> I'm using cvs2cl to generate version differences on branches, but I'm
having
> trouble with picking up changes where no change was previously there. I
> think the problem is one in cvs log, though, not cvs2cl.
>
> Here's the command I use
>
> cvs2cl -w -f ChangeLog_%1_To_%2.txt -r%1::%2
>
> the scenario that breaks it is:
>
> working on branch BRANCH1
>
> at TAG1, on BRANCH1 : file is on 1.23
> at TAG2, on BRANCH1 file is on 1.23.1.4 after changes
>
> the problem is that even when looking at 2 tags on the same branch, it is
> only after the first change to the file that it becomes _really_ on the
> branch, before that, the tag is still officially on the trunk.
>
> What would fix this for me is for 1.23 => 1.23.x.y to be considered on the
> same line. At the moment the line is only being start just after 1.23
which
> means I'm losing a significant number of changes out of these history
logs.
>
> are there any patches available for this problem? some others must have
had
> this problem with log -r.
>
> cheers,
> matt
I assume you are speaking of either
http://search.cpan.org/author/FLUFFY/CVSUtils-1.00/
or http://www.red-bean.com/cvs2cl/

the '-r' option to cvs2cl is for:
[-r, --revisions  Show revision numbers in output]

what I think you want is to pass options to cvs log so you should use -l
"options":
[-l OPTS, --log-opts OPTS Invoke like this "cvs ... log OPTS"]

if you want to pass revisions to cvs log I believe it should be something
like

cvs2cl -l "-r%1::%2" -w -f ChangeLog_%1_To_%2.txt

I use the global compress option as
cvs2cl.pl -g "-z9" -r -t -f cl.txt
so I think the line I gave you above will work, if cvs log will accept
whatever
"-r%1::%2" evaluates to.

--
I'd crawl over an acre of 'Visual This++' and 'Integrated Development
That' to get to gcc, Emacs, and gdb.  Thank you.
-- Vance Petree, Virginia Power



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

FW: first change on a branch causes no change to show up in -rTAGA::TAGB

[Matthew Herrmann]

oops sorry Larry, just saw your post after I sent my reply.

thanks for the input Larry and Todd, I'll upgrade asap.

-Original Message-
From: Matthew Herrmann [mailto:matt@;faredge.com.au]
Sent: Thursday, 14 November 2002 10:27
To: Todd Denniston
Cc: CVS Mailing List
Subject: RE: first change on a branch causes no change to show up in
-rTAGA::TAGB


Thanks todd, but with this option I see the exact behaviour.

The problem, as I verified is that the -rTAG1::TAG2 option
will not output any revisions when TAG1 and TAG2 are not "on the same
branch".

cvs log -rBRANCHTAG1::BRANCHTAG2 main\Main.bas

What is frustrating about this is that these tags _are_ on the same branch,
but that it is only after the first commit that the revision number moves
from being a trunk revision number to a branch revision number.

Ie. BRANCHTAG1 was taken before I made any changes to the file on the
branch, and BRANCHTAG2 was taken after I made some changes to it.

This effectively nullifies the use of cvs2cl in this manner or -rTAG1::TAG2,
unless one makes a dummy commit to every single file to force it to
'really' be on the branch, when one starts one. I personally find this a
pretty
messy workaround, especially since I can't apply it retrospectively.

The other alternative would be to say that, for a given revision

"X1.X2.X3. ... .Xn"

(ie. 1.52.1.20)

the file:

"X1.X2.X3. ... .Qn"

(ie. 1.52.1.13)

is on the branch (current behaviour), and so is

the file:

"X1.X2.X3. ... .X(n-2)"

(ie. 1.52)

and is before all revisions from "X1.X2.X3. ... .1" to "X1.X2.X3. ...
.infinity"

Are there any philosophical problems with this approach? I don't know of too
many people who fiddle with revision numbers, and even less who fiddle with
branch numbers.

I think the likelihood of someone branching off 1.52 and renumbering the
branch 1.53.1.2 extremely unlikely. In my reading of the Cederqvist,
renumbering the
branch in this way would actually go against what "branching of a file is"
actually means.

Intuitively, 1.53 is the parent of the branch 1.53.xx.yy.

What do other people think? Does anyone know a workable workaround, or know
of
a patch for this?

cheers,
matt

-Original Message-
From: [EMAIL PROTECTED]
[mailto:tdennist@;glock.ssa.crane.navy.mil]On Behalf Of Todd Denniston
Sent: Thursday, 14 November 2002 01:10
To: Matthew Herrmann
Cc: CVS Mailing List
Subject: Re: first change on a branch causes no change to show up in
-rTAGA::TAGB


Matthew Herrmann wrote:
>
> Hi All,
>
> I'm using cvs2cl to generate version differences on branches, but I'm
having
> trouble with picking up changes where no change was previously there. I
> think the problem is one in cvs log, though, not cvs2cl.
>
> Here's the command I use
>
> cvs2cl -w -f ChangeLog_%1_To_%2.txt -r%1::%2
>
> the scenario that breaks it is:
>
> working on branch BRANCH1
>
> at TAG1, on BRANCH1 : file is on 1.23
> at TAG2, on BRANCH1 file is on 1.23.1.4 after changes
>
> the problem is that even when looking at 2 tags on the same branch, it is
> only after the first change to the file that it becomes _really_ on the
> branch, before that, the tag is still officially on the trunk.
>
> What would fix this for me is for 1.23 => 1.23.x.y to be considered on the
> same line. At the moment the line is only being start just after 1.23
which
> means I'm losing a significant number of changes out of these history
logs.
>
> are there any patches available for this problem? some others must have
had
> this problem with log -r.
>
> cheers,
> matt
I assume you are speaking of either
http://search.cpan.org/author/FLUFFY/CVSUtils-1.00/
or http://www.red-bean.com/cvs2cl/

the '-r' option to cvs2cl is for:
[-r, --revisions  Show revision numbers in output]

what I think you want is to pass options to cvs log so you should use -l
"options":
[-l OPTS, --log-opts OPTS Invoke like this "cvs ... log OPTS"]

if you want to pass revisions to cvs log I believe it should be something
like

cvs2cl -l "-r%1::%2" -w -f ChangeLog_%1_To_%2.txt

I use the global compress option as
cvs2cl.pl -g "-z9" -r -t -f cl.txt
so I think the line I gave you above will work, if cvs log will accept
whatever
"-r%1::%2" evaluates to.

--
I'd crawl over an acre of 'Visual This++' and 'Integrated Development
That' to get to gcc, Emacs, and gdb.  Thank you.
-- Vance Petree, Virginia Power



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

first change on a branch causes no change to show up in -rTAGA::TAGB

[Matthew Herrmann]

Hi All,

I'm using cvs2cl to generate version differences on branches, but I'm having
trouble with picking up changes where no change was previously there. I
think the problem is one in cvs log, though, not cvs2cl.

Here's the command I use

cvs2cl -w -f ChangeLog_%1_To_%2.txt -r%1::%2

the scenario that breaks it is:

working on branch BRANCH1

at TAG1, on BRANCH1 : file is on 1.23
at TAG2, on BRANCH1 file is on 1.23.1.4 after changes

the problem is that even when looking at 2 tags on the same branch, it is
only after the first change to the file that it becomes _really_ on the
branch, before that, the tag is still officially on the trunk.

What would fix this for me is for 1.23 => 1.23.x.y to be considered on the
same line. At the moment the line is only being start just after 1.23 which
means I'm losing a significant number of changes out of these history logs.

are there any patches available for this problem? some others must have had
this problem with log -r.

cheers,
matt



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

perl script to tag message text

[Matthew Herrmann]

hi all,

i was wondering if anyone had a simple script where you could say:

script.pl modulename "message.*" TEMP_TAG

(or similar) and it would tag each file with that message -- throwing an
error if it didn't.

I know this sounds kinda specific but hopefully someone has already needed
it. I want to use it to do code reviews on checked in code between versions,
but fishing through the cvs log output for individual files is a major drag.
I could just find the two commit messages in the cvs2cl output, tag them,
rdiff them, then delete the tags.

anyway, if noone's done it, i'll have a shot and post it up here.

cheers,
matt



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

users of mcvs?

[Matthew Herrmann]

hi all,

just wanting to find out how many people are using mcvs and what their
experiences have been?

i'm considering using it and wanted to get a feel for whether there is any
community for it. cvs
has many flaws, but they are overcome in large part by the community
activity on this newsgroup.

cheers,

matt



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

A nifty way to merge after changing directory structures?

[Matthew Herrmann]

Hi All,

I want to refactor my project tree to break out one large project into
smaller projects. The main issue at the moment is of course that I will lose
my ability to merge in bug fixes. But -- I think I have found a way to do
it.

I am using Win32 with linux tools. I can create hard links using a port of
the 'ln' command.

I would like to do something like the following:

Files were originally in:
\main

Broken into:
\main\subproject1
\main\subproject2
\main\subproject3

Most of the time, I just work with these new folders. I can only get history
from these folders. That's not a problem.

However, when I merge, I would like to do a:
ln subproject1\*.* .
ln subproject2\*.* .
ln subproject3\*.* .

to make the files appear in their original locations. Then,

cvs up -jMERGEPOINT_29 -jMERGEPOINT_30

to apply the merged changes (which will automagically get applied to the
linked files in the new folders). Then, I can simply delete these temporary
files. The major problem at this point is that a merge will probably not
happen because the deleted files from this folder are "no longer pertinent".

Here's what I would like to do :

cvs rdiff -rMERGEPOINT_29 -rMERGEPOINT_30 project > changes.txt
patch changes.txt .

but the changes.txt file won't create and remove files like "cvs up" would,
and I have never succeeded in getting patch to work using repository rdiff
output.

Any suggestions? This would really make my life a lot easer.

TIA,

Matthew Herrmann
--
Far Edge Technology
Level 11, 80 Mount St
North Sydney NSW 2060
Australia

Ph: 02 9955 3640
Mob: 0404 852 537



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

checkout without modifying the Entries file

[Matthew Herrmann]

Hi All,

I've developed a release script which is version controlled, and which
checks out and compiles a particular version of the product:

ie

cvs co proj
cd proj
release PROJ_V_1_1_1

which does:
cvs co -rPROJ_V_1_1_1 -d%TEMP%\proj_temp
cd %TEMP%\proj_temp
build

the problem is that since the checkout happened inside the project folder,
the temp directory gets added to the entries folder and cvs tries to update
the temp folder whenever the project folder gets updated.

i'd rather not use "cvs export" because i like the idea of the release
script updating version numbers based on the sticky tag.

is there a way to get around this apart from temporarily renaming the CVS
folder to pretend we're not in a checked out folder?

Regards,

Matthew Herrmann
--
Far Edge Technology
Level 11, 80 Mount St
North Sydney NSW 2060
Australia

Ph: 02 9955 3640
Mob: 0404 852 537



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

moving tags

[Matthew Herrmann]

hi all,

more a question -- when i do "cvs rtag -rEXISTING TAG project" and the tag
"TAG" exists, i get a warning message for only 2 of the files in the module,
which were recently added.

if it just gave a warning for 1 file, that would suggest that it failed on
the first and gave up, which is fine. Giving only 2 warnings suggests to me
that most of the files were successfully retagged (which shouldn't be?)

W proj/Release.bat : TAG1 already exists on version 1.1.2.3 : NOT MOV
ING tag to version 1.1.2.4
W proj/utils/stkdir.exe : TAG1 already exists on version 1.1.2.1 : NO
T MOVING tag to version 1.1.2.2

could anyone explain why 2 messages and not more or less appear when doing
this?

Regards,

Matthew Herrmann
--
Far Edge Technology



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

RE: make cvs text agnostic?

[Matthew Herrmann]

Okay, agreed, but let me put it this way:

you are working on a project with files called *.doc, some containing text
and some containing binary. People have complained they don't like adding
the -kb and many get it wrong.

do you
a) take the error-prone option of people setting -k sticky flags themselves?
(yuck!) (then they go and throw weird variants on it with keyword conversion
and what not and see what happens)
b) say "well from now on don't call your text files *.doc, call them *.txt"
c) invent a heuristic detector which understands 382 languages and 3483
filetypes

whatever little problems there may be, i really think (b) is the easiest.
this really is a case of the "shortest path".

if files don't have meaningful extensions, the purpose of which is to convey
a unique file type, then the responsibility lies _there_ to fix the problem.
autodetection of types is a drastically appaling workaround for something
that just doesn't need to be a big issue.

(and can't cvswrappers files be defined on a directory level? then, wrappers
could be set up for each folder and the different types of documentation
stored in each one of these)

-Original Message-
From: Paul Sander [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 29 August 2002 10:16
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: make cvs text agnostic?


>--- Forwarded mail from [EMAIL PROTECTED]

>re this conversation of file types -- why autodetect them, isn't that the
>whole point
>of a file type, given in every file's extension? heuristic detection of
>binariness -- yuck!

That only works if you have a strict naming convention.  The canonical
counterexample is the ".doc" extension which can represent any one of
dozens of data types, some of which are pure ASCII and some of which
are not.  Many shops have never standardized the tool they use to produce
documentation (and therefore have a few), and several tools default to
that specific extension.

>a mechanism already exists to tell with this problem -- why don't people
>just make a whopper of a cvswrappers file and then be done with it?

Because cvswrappers won't work with this counterexample.

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




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

Re: make cvs text agnostic?

[Matthew Herrmann]

hi all,

re this conversation of file types -- why autodetect them, isn't that the
whole point
of a file type, given in every file's extension? heuristic detection of
binariness -- yuck!

a mechanism already exists to tell with this problem -- why don't people
just make a whopper of a cvswrappers file and then be done with it?

that's what we've got running in our shop, and i haven't typed a "-kb" since
i don't know when...


Matthew Herrmann
--
Far Edge Technology
Level 11, 80 Mount St
North Sydney NSW 2060
Australia

Ph: 02 9955 3640
Mob: 0404 852 537



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

"failed to read diff file header" for binary files

[Matthew Herrmann]

hi all,

typing:

cvs rdiff -rTAG1 -rTAG2 project > test.txt

cvs server: failed to read diff file header /tmp/cvsR485Y3 for
ExperimentInfo.frx,v: end of file

using 1.11.1.2 on redhat server. it seems to be for files marked with -kb.

should i be worried about this? the end of file bit has me a little spooked,
like part of the file
is corrupted, but i only see it when doing diffs since its a doesn't usually
access that part... (or similar)

TIA,

Regards,

Matthew Herrmann
--
Far Edge Technology
Level 11, 80 Mount St
North Sydney NSW 2060
Australia

Ph: 02 9955 3640
Mob: 0404 852 537




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

RE: new feature suggestion: 3-way conflict indicators

[Matthew Herrmann]

Hi Greg,

I just looked at sanity.sh (it's kind of scary when you mistake the test
cases for code -- it looks like the obfuscated C competition on steroids!)
and the CVS code itself, and there's a fair bit of disruption needed to get
it a command-line parameter to the RCS_Merge command. i think i'll just take
your suggestion, and patch our server with the -AT and be done with it.
Thanks for the info about the no duplication, that means then that conflict
markers will work well for both multi-developer-style merges and
update-from-bugfix merges. I'll need to let the guys know here how the new
system works but this will sure save me some headaches I can assure you!

Many thanks,
Matthew

-Original Message-
From: Greg A. Woods [mailto:[EMAIL PROTECTED]]
Sent: Sunday, 23 June 2002 03:31
To: Matthew Herrmann
Cc: CVS Mailing List
Subject: Re: new feature suggestion: 3-way conflict indicators


[ On Saturday, June 22, 2002 at 13:51:15 (+1000), Matthew Herrmann wrote: ]
> Subject: Re: new feature suggestion: 3-way conflict indicators
>
> but, if i were to include this as a new argument to cvs update as an
> argument (-3 i quite like), it wouldn't affect sanity.sh at all, since
those
> scripts would run exactly as before

I think the only proper way to display merge conflicts is with '-AT'.  I
think '-E' is bogus and misleading in almost all cases.

(Note that '-A' doesn't show unnecessary duplication -- it only shows
old and new if that's all that's necessary.)

...


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

Re: new feature suggestion: 3-way conflict indicators

[Matthew Herrmann]

but, if i were to include this as a new argument to cvs update as an
argument (-3 i quite like), it wouldn't affect sanity.sh at all, since those
scripts would run exactly as before

of course, it would probably be a good idea to include some sanity checks
eventually.

If I wrote a patch to include the functionality with a -3 option to CVS,
with following help:

Usage: cvs update [-APdflRp] [-k kopt] [-r rev|-D date] [-j rev]
[-I ign] [-W spec] [files...]
...
-k kopt Use RCS kopt -k option on checkout.
-r rev  Update using specified revision/tag (is sticky).
-D date Set date to update from (is sticky).
-3  Include original text when marking conflicts.
-j rev  Merge in changes made between current revision and rev.
-I ign  More files to ignore (! to reset).
...

then people could turn it on just when they were using cvs update -j, but it
wouldn't
give too much info when people were just editing in a normal context (where
it is
overkill since the original source on both people's working copies are
usually close to
identical)

Would this be likely to be accepted into a new release? I mean, it doesn't
sound particularly risky? It's just like allowing users to pass through
parameters to the "cvs diff" command... it won't offend anyone, and i think
my last email gave some pretty good reasons to why it _should_ be included.

i'm d/l'ing the source now, i'll check out making a full patch that includes
all the frills like the new command-line parameter. if it's straightforward
enough, i'll check out updating sanity.sh (though this won't _need_ to be
updated if i patch my way, it just _should_ be)... biggest prob here is i'm
on a win2k box, linux is only on the server which makes things a bit
trickier.

rgds,
matt

On Tue, Jun 18, 2002 at 11:33:18PM -0400, Greg A. Woods wrote:
> [ On Wednesday, June 19, 2002 at 09:04:37 (+1000), Matthew Herrmann
wrote: ]
> > Subject: new feature suggestion: 3-way conflict indicators
>
> The core patch is (including some extra unrelated fixes):

Without the unrelated fixes, it's a one-character change (this is
from 1.11.1p1, but I doubt it's changed significantly for
1.11.2).  Be warned though; this patch will make sanity.sh fail
big-time.



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

RE: new feature suggestion: 3-way conflict indicators

[Matthew Herrmann]

greg (or anyone that remembers), could i ask, why this feature wasn't
included in the main build then? did people find it too complicated?
unnecessary? noone got around to it?

-Original Message-
From: Greg A. Woods [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 19 June 2002 13:33
To: Matthew Herrmann
Cc: CVS Mailing List
Subject: Re: new feature suggestion: 3-way conflict indicators


[ On Wednesday, June 19, 2002 at 09:04:37 (+1000), Matthew Herrmann wrote: ]
> Subject: new feature suggestion: 3-way conflict indicators
>
> I have a suggestion for a new feature I think would be exceedingly useful
> for difficult merges. The idea is to have 3-way conflict indicators.

I suggested the same, and provided full patches to implement them,
several years ago!  ;-)  See the archives.  (I think...)

The core patch is (including some extra unrelated fixes):

$ cvs diff rcscmds.c
Index: rcscmds.c
===
RCS file: /home2/cvsroot/ccvs/src/rcscmds.c,v
retrieving revision 1.50
diff -c -r1.50 rcscmds.c
*** rcscmds.c   14 Feb 2001 04:31:27 -  1.50
--- rcscmds.c   19 Jun 2002 03:31:51 -
***
*** 245,254 
--- 245,258 
  char *tmp1, *tmp2;
  char *diffout = NULL;
  int retval;
+ struct stat file_info;

  if (options != NULL && options[0] != '\0')
assert (options[0] == '-' && options[1] == 'k');

+ if (CVS_STAT (workfile, &file_info) < 0)
+   error (1, errno, "could not stat %s", workfile);
+
  cvs_output ("RCS file: ", 0);
  cvs_output (rcs->path, 0);
  cvs_output ("\n", 1);
***
*** 298,305 
 only for diagnostic messages -- CVS no longer forks to run diff3.
*/
  diffout = cvs_temp_name();
  call_diff_setup ("diff3");
! call_diff_arg ("-E");
! call_diff_arg ("-am");

  call_diff_arg ("-L");
  call_diff_arg (workfile);
--- 302,308 
 only for diagnostic messages -- CVS no longer forks to run diff3.
*/
  diffout = cvs_temp_name();
  call_diff_setup ("diff3");
! call_diff_arg ("-ATam");

  call_diff_arg ("-L");
  call_diff_arg (workfile);
***
*** 321,326 
--- 324,332 

  if (diffout)
copy_file (diffout, workfile);
+
+ if (chmod (workfile, file_info.st_mode) < 0)
+   error (0, errno, "cannot change mode of file %s", workfile);

  /* Clean up. */
  {


--
Greg A. Woods

+1 416 218-0098;  <[EMAIL PROTECTED]>;  <[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: new feature suggestion: 3-way conflict indicators

[Matthew Herrmann]

Thanks Greg, I'll look for them.

I suspected this idea would be up your alley for some reason.

-- matt

-Original Message-
From: Greg A. Woods [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 19 June 2002 13:33
To: Matthew Herrmann
Cc: CVS Mailing List
Subject: Re: new feature suggestion: 3-way conflict indicators


[ On Wednesday, June 19, 2002 at 09:04:37 (+1000), Matthew Herrmann wrote: ]
> Subject: new feature suggestion: 3-way conflict indicators
>
> I have a suggestion for a new feature I think would be exceedingly useful
> for difficult merges. The idea is to have 3-way conflict indicators.

I suggested the same, and provided full patches to implement them,
several years ago!  ;-)  See the archives.  (I think...)

The core patch is (including some extra unrelated fixes):

$ cvs diff rcscmds.c
Index: rcscmds.c
===
RCS file: /home2/cvsroot/ccvs/src/rcscmds.c,v
retrieving revision 1.50
diff -c -r1.50 rcscmds.c
*** rcscmds.c   14 Feb 2001 04:31:27 -  1.50
--- rcscmds.c   19 Jun 2002 03:31:51 -
***
*** 245,254 
--- 245,258 
  char *tmp1, *tmp2;
  char *diffout = NULL;
  int retval;
+ struct stat file_info;

  if (options != NULL && options[0] != '\0')
assert (options[0] == '-' && options[1] == 'k');

+ if (CVS_STAT (workfile, &file_info) < 0)
+   error (1, errno, "could not stat %s", workfile);
+
  cvs_output ("RCS file: ", 0);
  cvs_output (rcs->path, 0);
  cvs_output ("\n", 1);
***
*** 298,305 
 only for diagnostic messages -- CVS no longer forks to run diff3.
*/
  diffout = cvs_temp_name();
  call_diff_setup ("diff3");
! call_diff_arg ("-E");
! call_diff_arg ("-am");

  call_diff_arg ("-L");
  call_diff_arg (workfile);
--- 302,308 
 only for diagnostic messages -- CVS no longer forks to run diff3.
*/
  diffout = cvs_temp_name();
  call_diff_setup ("diff3");
! call_diff_arg ("-ATam");

  call_diff_arg ("-L");
  call_diff_arg (workfile);
***
*** 321,326 
--- 324,332 

  if (diffout)
copy_file (diffout, workfile);
+
+ if (chmod (workfile, file_info.st_mode) < 0)
+   error (0, errno, "cannot change mode of file %s", workfile);

  /* Clean up. */
  {


--
Greg A. Woods

+1 416 218-0098;  <[EMAIL PROTECTED]>;  <[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

update -j ignoring whitespace

[Matthew Herrmann]

Hi All,

I was wondering if someone could suggest how to do a merge using update -j,
while ignoring case changes and whitespace.

for a single file, i can use:

cvs diff -c -i -w -rTAG1 -rTAG2 file.cls > patch.txt

patch file.cls patch.txt

but obviously this is clumsy for multiple files. i tried running patch with
the output of rdiff but it didn't work (i was hoping would just magically
work, but i figured out all it stores in the patch file is unix folder names
like /proj/folder1/folder2 from the repository, not from my pc. so, somehow,
patch would have to automagically decode the proj/folder1 and work out in
this case it meant c:\prog\projects\proj_v4\folder1 because i was in the
proj_v4 directory at the time. or something. in any case, i ran it and it
told me about lots of chunks that were ignored (or something equally
emotive, I can't remember the exact error)

has anyone in windows with native exe (not cygwin) unix tools got patching
with rdiff generated files to work?

Alternatively, it would be great for update -j to have some options, like -i
and -w (from diff), since i'm guessing internally it's just calling diff
anyway and applying the patch that generates to each file in the current
folder. to my eye, the only tricky part would be working out what to label
the command-line parameters. or am i mistaken?

TIA,

regards,
matthew herrmann


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

new feature suggestion: 3-way conflict indicators

[Matthew Herrmann]

Hi All,

I have a suggestion for a new feature I think would be exceedingly useful
for difficult merges. The idea is to have 3-way conflict indicators.

THE PROBLEM:
When I do a difficult merge, i sometimes usually go off an rdiff output
while i'm tracing through the conflicts to make sure i capture the changes
properly. I find this helpful determining changes causing conflicts.

But surely, shouldn't the conflict markers themselves be adequate to resolve
a merge? (and the reason they are thrown in in the first place?) Not so. I
believe that the current system of conflict markers is subtly (and
dangerously) inadequate, and lacks some vital information to resolve
conflicts safely.

THE EXAMPLE:
Let me give an example to demonstrate the problem, and my proposed
solution...

here we have a conflict in some code after performing a bugfix merge off a
production branch onto the development trunk, shown below. Looks simple?
Someone's obviously gone and changed the indenting (note the extra spaces)
in this part of the code because they put it in a for loop, which is why the
auto merger couldn't put in the 10 => 9 change, and the i => i+1 change.

FILE:

... rest of file

  for (j=0; j<100; j++) {
<<<<<<<<<<<<<<<<<<<<<<<<<<<
  for (i=0; i<10; i++) {
   perform_operation(i+1);
  }

---
 for (i=0; i<9; i++) {
  perform_operation(i);
 }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
  }
  ... rest of file


WRONG! The change was only to change i to i+1, but the 10 should not have
been changed! 10 had been changed to 9 in the trunk, but not on the branch,
and had been done that way for good reason. But now, we have clobbered our
trunk's code change from 10=>9 (possibly now a new bug) with old code from
the bugfix branch. Incredible how such an innocent looking conflict can be
really nasty... Imagine all the bugs this could create. This shows the
fundamental weakness in using standard conflict markers to merge changes.

I reckon this weakness is the main reason why so many people on this list
(Greg for example) are horrified by code beautifiers, because they make this
kind of error really likely. Why? Not because code beautification is
inherently _dangerous_ (though some might say useless), but because it means
you need to perform conflict resolution using conflict markers, much more
often, which _are_ (IMHO).

THE SOLUTION:
How about this? Now it's obvious that the change was in fact to fix the
out-of-range error caused by i-1, and that the 9 -> 10 difference was
because of something else.

OLD UNFIXED <<<<<<<<<<<<<<<<<<<
  for (i=0; i<10; i++) {
!  perform_operation(i);
  }
FIXED -
  for (i=0; i<10; i++) {
!  perform_operation(i+1);
  }
---
 for (i=0; i<9; i++) {
  perform_operation(i);
 }
NEW UNFIXED >>>>>>>>>>>>>>>>>>>

Now, the person merging would be very clear that only the i+1 was included
in the change, and would apply that (or something in the same 'spirit').

Please consider this, I think this would be a great idea and would add great
value to the concurrent edits model.

What do other people think? Anyone else agree, or disagree?

Note that that this effectively eliminates the _DANGER_ aspect out of the
problems in reformatting code in the trunk and causing nonsense conflicts.
It's now simply just _annoying_ and time consuming to the person merging,
rather than risking clobbering changes (although of course human error in
manual merges is still, as always, a factor, though i would argue now far
less likely, and certainly no more error prone than non-conflicting
automatic merges).

PS> We have just installed the new version of CVS... thankyou to all those
who contributed, especially Larry for incorporating the -rR1::R2 request,
appreciated.

Regards,

Matthew Herrmann
--
Far Edge Technology


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

AW: Commit Error

[Matthew Herrmann]

Hi Peter

Re: the problem with uppercase/lowercase files -- I had exactly the same
thing. it's perfectly reproducible with Win2K client, linux redhat server,
and it occurs when a filename with a different case is added on a branch
when it exists with a different case on the trunk or vice versa. It gave me
this error:

RCS file: /public/Development/CVS/rotorgene/main/Attic/build.bat,v
done
cvs [server aborted]: received abort signal
cvs: commit.c:2044: checkaddfile: Assertion `*rcsnode == ((void *)0)'
failed.
cvs commit: saving log message in C:\DOCUME~1\matthew\LOCALS~1\Temp\20

This is on 1.11.1.1p

fyi

Cheers,
Matt


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

vb6 form/control normaliser for better merges - *nix users press delete now

[Matthew Herrmann]

gday,

just finished working on a vb6 form/control normaliser, which sorts the GUI
elements in *.frm and *.ctl files (since they are always saved in quasi
random order by visual basic). so when you add a new command button to a
complicated form, you get:
> Begin VB.CommandButton Blah
>Caption = "OK
> End

as the change, instead of spurious line changes due to things jumping
around. anyone who's typed "cvs diff" to see what they changed on a form
would know what i mean.

this may be useful for vb programmers who would like to do automatic merges
of form and control files across branches instead of just code.

shoot me an email if you're interested and i'll mail the code...

cheers,
matt


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

Re: Sharing a file between to different modules (A dead-horse topic?)

[Matthew Herrmann]

Hi Casey,

I think I understand what you want to do, but it needs a fair bit more
effort to set up than on other systems. I'm guessing you've got a
Utility.java file or something similar in which you throw common useful
functions to reuse across apps.

Here's one problem with just using a shared file, as you would in VSS or
similar:

you have a utility function called:
Folder getDesktopFolder()

and you update it to have the following definition, to account for a
weirdness on NT systems:
Folder getDesktopFolder(boolean usingNT)

Now, you have to check every app which uses this file to make sure it still
compiles. A change to a shared file must _always_ be reflected in other
code.

Using the shared project approach, you can solve this problem and future
proof your apps. Make a build script which includes:

cvs co -rSHAREDLIB_VERSION_5_FIXES sharedlib

as a line. Then, users needs to run build.bat or build.sh when they check
out.

SHAREDLIB_VERSION_5_FIXES would be the branch tag of all compatible changes
to the library sharedlib that this code requires. You would not want to
automagically copy the utility file into your own directory, since you can't
then check changes back into that branch. (on *nix you may be able to use a
symlink to do the same thing though).

You could then commit fixs to the library and the changes would reflect in
other apps. Now, for an incompatible change like the above one, you would
make a new branch, and check that version out. Other apps will still use the
old branch of the file, and not require updating.

Note that if most of the time, you are making compatible changes, like
adding functions, fixing bugs, etc., you don't need to worry about
branching. It's just when old clients would get broken.

If you have a project folder format like:

project/
   main/
   docs/
   testscripts/
   sharedlib/
   build.sh

then the sharedlib folder fits in nicely.

Advantages:
- You can fix your libraries while you work without needing to redeploy or
release manage etc.
- You can fix the same bugs in other apps
- You don't have to worry about chasing up every other app to resolve
incompatibilities
- Developers won't do the same silly things to the shared code as they might
to their own (like decide to fix function name capitalisation in a
case-sensitive language)

Disadvantages:
- Could be a pain making those branches (maybe a script would help)
- Can only use "cvs tag" in this repo.

In our shop, we have a central library that developers from our company and
different clients we contract to commit to. Keeping it separate, in our
experience, improves code quality since the code is in a way "published" and
people take more care.

Anyway, just some thoughts...

HTH

Regards,

Matthew Herrmann
--
Far Edge Technology
Level 11, 80 Mount St
North Sydney NSW 2060
Australia


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

RE: can't add file to branch, not permissions problem

[Matthew Herrmann]

yup, it's on windows 2k, but just using command-line cvs, not wincvs. I
guess I should have a bit of a hack at it to see if I can put a check in for
win32 builds only, shouldn't be too difficult nor risky -- just need some
more time...

cheers,
matt

> -Original Message-
> From: Teala Spitzbarth [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, 15 May 2002 13:45
> To: Matthew Herrmann; CVS Mailing List
> Subject: RE: can't add file to branch, not permissions problem
>
>
> Oh, that sounds nasty - is it a case issue with using WinCVS?
> I can't imagine you would get case issues on a Unix client
> We get directory issues with lower case getting converted to
> all caps frequently while using WinCVS back to a Linux server.
>
> I sure hope all the log fixes & syntax changes are in 1.11.2 and
> that the News file just didn't include those details!  The exclusive
> revision ranges for log ::, is listed as going into 1.11.1
>
> Cheers,
> Teala
>
>
>  Yahoo! Groups
Sponsor -~-->
> Tied to your PC? Cut Loose and
> Stay connected with Yahoo! Mobile
> http://us.click.yahoo.com/QBCcSD/o1CEAA/sXBHAA/dpFolB/TM
> -~->
;
>
> To unsubscribe from this group, send an email to:
> [EMAIL PROTECTED]
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>



 Yahoo! Groups Sponsor -~-->
Take the Yahoo! Groups survey for a chance to win $1,000.
Your opinion is very important to us!
http://us.click.yahoo.com/NOFBfD/uAJEAA/Ey.GAA/dpFolB/TM
-~->

To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/




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

RE: can't add file to branch, not permissions problem

[Matthew Herrmann]

argh! the one on the branch was build.bat and the other on the mainline was
Build.bat

i mean, it's crazy trying to have files differentiated only by case in a
repo, but it would really help if there was a message telling me I was about
to do something stupid. I got this:

RCS file: /public/Development/CVS/rotorgene/main/Attic/build.bat,v
done
cvs [server aborted]: received abort signal
cvs: commit.c:2044: checkaddfile: Assertion `*rcsnode == ((void *)0)'
failed.
cvs commit: saving log message in C:\DOCUME~1\matthew\LOCALS~1\Temp\20

and now I actually remember getting this problem before, not that the error
message jogged my memory :(

-- matthew

-Original Message-----
From: Matthew Herrmann [mailto:[EMAIL PROTECTED]]
Sent: Friday, 10 May 2002 11:51
To: CVS Mailing List
Subject: can't add file to branch, not permissions problem


hi all,

i'm getting an error trying to commit a new file on a branch. i'm using
1.11.p1 with client/server (win2k client, redhat linux server).

checked out a fresh copy of the data:

>cvs add build.bat
cvs server: use 'cvs commit' to add this file permanently

>cvs commit
cvs server: cannot lock
`/public/Development/CVS/rotorgene/main/Attic/build.bat,
v'.
cvs commit: saving log message in C:\DOCUME~1\matthew\LOCALS~1\Temp\17

now i checked the directory and there are no lock files, and I can touch a
new file in the repo's dir, so i can't see the permissions being an issue.

any ideas?

also, is the newly released version 1.12 what _was_ the dev version about 2
months ago, or have they made a new minimal patch? On the website it only
shows 4 things or so that have changed, or is that just a summary? (ie does
it have the fixed log "::" command and the fixed rlog over branches?)

thanks,

Matthew Herrmann
--
Far Edge Technology
Level 11, 80 Mount St
North Sydney NSW 2060
Australia

Ph: 02 9955 3640
Mob: 0404 852 537


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

can't add file to branch, not permissions problem

[Matthew Herrmann]

hi all,

i'm getting an error trying to commit a new file on a branch. i'm using
1.11.p1 with client/server (win2k client, redhat linux server).

checked out a fresh copy of the data:

>cvs add build.bat
cvs server: use 'cvs commit' to add this file permanently

>cvs commit
cvs server: cannot lock
`/public/Development/CVS/rotorgene/main/Attic/build.bat,
v'.
cvs commit: saving log message in C:\DOCUME~1\matthew\LOCALS~1\Temp\17

now i checked the directory and there are no lock files, and I can touch a
new file in the repo's dir, so i can't see the permissions being an issue.

any ideas?

also, is the newly released version 1.12 what _was_ the dev version about 2
months ago, or have they made a new minimal patch? On the website it only
shows 4 things or so that have changed, or is that just a summary? (ie does
it have the fixed log "::" command and the fixed rlog over branches?)

thanks,

Matthew Herrmann
--
Far Edge Technology
Level 11, 80 Mount St
North Sydney NSW 2060
Australia

Ph: 02 9955 3640
Mob: 0404 852 537


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

apply rdiff output to patch multiple files

[Matthew Herrmann]

Hi All,

I am using 1.11.1.p1 and I'm getting basically one conflict per change on my
latest merge.

I'm using mergepoints ie.

cvs update -j ROT_4_6_1_MERGEPOINT_1 -j ROT_4_6_1_MERGEPOINT_2

in the current directory which I expect would generate a diff between the
two tags and apply the changes. I read there is a bug in the latest
production cvs release where conflicts are spuriously generated. Even in
code which I know has not been modified, it is creating a conflict.

I thought I might be able to avoid this by doing my merge in two steps:
 1) generate an rdiff file for the directory (maybe specifying case
insensitivity, ignore blank line changes etc. to reduce conflicts)
 2) apply this file using patch

as far as I know, patch only runs on single files. Any way to run rdiff
output? And any idea whether this will help me with my problem? (or maybe
some other workaround, like a switch to specify etc.)

I don't really want to get the latest development release since I'll have to
compile it on two servers and I suppose then update all the client versions
running on Win2k too.(unless there are pre-release binaries available).

TIA

Regards,

Matthew Herrmann
--
Far Edge Technology
Level 11, 80 Mount St
North Sydney NSW 2060
Australia

Ph: 02 9955 3640
Mob: 0404 852 537


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

RE: renaming under CVS

[Matthew Herrmann]

Hi Paul, Noel,

I was thinking about a similar idea to yours. I also thought of another way
to allow renames etc, although it would probably be grossly inefficient
though elegant in its own way:

Store all the directories, files, etc. in a single mergeable text file
format. Then, on commits, the directories are put back into this text file
which is commited. On update, the existing files are merged into a text file
then a normal update is performed. Then, from that file, the individual
files are broken out.

Ads:
- Metadata can be stored, file location etc. handling renames
- Revision numbers are unique and can become useful (like give me a diff
versus the last checkin)
- Commits are atomic
- Branching etc. is trivial, don't have to worry about "oh i lost that file"
etc.
- Diffs between two tags work better because the revision numbers are
incremented every time a change is made in the project

Disads:
- slow (i'm guessing cvs is optimised to work on lots of smallish files)
- concurrent dev is slowed by requiring a cvs update on basically every
commit, not just when you have changed the same file as someone else.
- it kind of undoes the point of cvs

Just thought i'd throw that in -- the disadvantages most likely render it
impractical, however.

Regards,

Matthew Herrmann
--
Far Edge Technology
Level 11, 80 Mount St
North Sydney NSW 2060
Australia

Ph: 02 9955 3640
Mob: 0404 852 537


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

Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not

[Matthew Herrmann]

Hi All,

I think in this discussion it comes down to useability. The key idea is that
CVS is a solution for versioning binary files, but not a _scalable_ solution
for versioning binary files. It can handle them in bits and pieces. All this
means is that if you are a purist, then you will reject binary files of any
shape or form from the word go. If you are a pragmatist, you'll add a couple
and hope you don't get too many more.

The basic measure of whether you should import binary files into a
repository is whether or not you find it annoying. Text files are transfered
very quickly over remote connections, and binary files can take a long
time -- just to confirm that in fact they hadn't changed (when date stamps
get out of whack). If you're on a local network, then this probably doesn't
matter. If you're working remotely, then you'll quickly get very frustrated.
And I recommend that when it frustrates you, change it. If it doesn't annoy
you -- why bother?

My advice is to go with the pragmatic solution and put in the little
blah.ico files your project needs, but be aware that when this grows, you'll
need to make some sort of script that compares file size (as an easy way)
for your required binaries and puts up a message if they're too big. It
could also store an FTP url in a mergeable text file which the user can
refer to when they discover that their binary files are incorrect. (This
could even be automated)

So, there's no need for the religious war. People should simply be aware of
the limitations, and accept that when a non-scalable solution is chosen,
they may need to change paradigm after a certain size. (CF: "Why can't I
support more than 100 simultaneous users with Access 2000?" Which still
doesn't rule out Access as a backend for small non-critical database jobs.)

Regards,

Matthew Herrmann
--
Far Edge Technology
Level 11, 80 Mount St
North Sydney NSW 2060
Australia

Ph: 02 9955 3640
Mob: 0404 852 537


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

script to handle version control of sql server databases

[Matthew Herrmann]

Hi All,

I've been working on an SQL Server database as part of a project, and I
created the following script to allow me to do all my development in SQL
Server, but still get cvs text-based version control without 20 mouse clicks
to generate scripts from sql server. It was originally in Python, but it's
COM support broke unexpectedly going from SQL7 to 2000 and I couldn't be
bothered working out why it happened, so I translated it to VBS.

I'm also using a script which generates batch files to read/write bcp text
files (but this is less pluggable). I saw some posts about this a while ago
and thought this would be of use to SQL Server developers. The version
control tracking is excellent from this, for example, you change a field
name, and when you regenerate the scripts, you'll just get something like :

<first_date  datetime
--
>initial_date  datetime

Please email me if you'd like additional help about doing this, we got it
working here really smoothly.

Regards,

Matthew Herrmann
--
Far Edge Technology
Level 11, 80 Mount St
North Sydney NSW 2060
Australia

Ph: 02 9955 3640
Mob: 0404 852 537



' GenerateSQL.vbs
'
' (C)Copyright 2002 Matthew Herrmann, Far Edge Pty. Ltd.
' email: [EMAIL PROTECTED]
' Far Edge Pty. Ltd.
'
' A script to automate getting an entire database in scripted form from
' Microsoft SQL Server. Does more than the scripts that SQL Server generates
' in that it creates the DROP DATABASE, CREATE DATABASE commands. You should
' then have a script which populates your empty database with test data.
'
' Known problems : Doesn't script permissions for tables, this isn't here
' yet because you should never need it (!)
' Doesn't do user-defined types etc. since I don't use them.
' Doesn't script data values as of yet -- this would be very cool.

Const SQLDMOScript_DRI_Defaults = &H200
Const SQLDMOScript_Permissions = 34
Const SQLDMOScript_DRI_Checks =  &H100
Const SQLDMOScript_DRI_ForeignKeys = &H800
const SQLDMOScript_PrimaryObject = 4
const SQLDMOScript_NoDRI = &H200
Const SQLDMOScript_DRI_PrimaryKey = &H1000
Const SQLDMOScript_DRI_UniqueKeys = &H400
Const SQLDMOScript_DRIIndexes = &H1


Set FSO = CreateObject("Scripting.FileSystemObject")

''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
''''''''''
' Utility Functions
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
''''''''''

' Removes extraneous whitespace and SET QUOTED... lines for the given SQL
file
Function CleanFile(inFilename, outFilename)

Dim sText
Set Stream = FSO.OpenTextFile(inFilename)

sText = ""
Do While Not Stream.AtEndOfStream
sText = sText & Stream.ReadLine & vbCrLf
Loop

Stream.Close

' Clean up garbage
for i = 0 to 4
sText = replace(sText, "SET QUOTED_IDENTIFIER  OFFSET ANSI_NULLS
ON " & vbcrlf & _
"GO" & vbcrlf & vbcrlf,"")
sText = replace(sText, "SET QUOTED_IDENTIFIER  ONSET ANSI_NULLS
ON " & vbcrlf & "GO" & _
vbcrlf & vbcrlf,"")
sText = replace(sText, vbcrlf & vbcrlf & vbcrlf,vbcrlf & vbcrlf)
next

Set Stream = FSO.CreateTextFile(outFilename)
Stream.WriteLine sText
Stream.Close
End Function

'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''&#

RE: request for log option to specifically exclude the first tag, workaround for cvs log -r -r

[Matthew Herrmann]

just to clarify, it should include TAG2 only in the case where a tag does
not exist for TAG1...

-Original Message-
From: Larry Jones [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 9 January 2002 05:00
To: Matthew Herrmann
Cc: [EMAIL PROTECTED]
Subject: Re: request for log option to specifically exclude the first
tag, workaround for cvs log -r -r


Matthew Herrmann writes:
>
> since it would be used pretty commonly -- shame -rTAG1::TAG2 doesn't do
what
> people would expect it to do.

Would anyone object to changing it so that it does revisions after TAG1
and not after TAG2 rather than after TAG1 and before TAG2 (e.g.,
currently it is exclusive of both TAG1 and TAG2, the change would be to
make it inclusive for just TAG2)?

-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

cvs diff -D "yesterday" returns lots of changes on branch on 1.11

[Matthew Herrmann]

Hi,

cvs diff -D "yesterday" returns lots of spurious changes on a branch on
1.11, when I use a release tag instead it works correctly.

has this bug been fixed on the dev version?

Regards,

Matthew Herrmann
--
Far Edge Technology
Level 11, 80 Mount St
North Sydney NSW 2060
Australia

Ph: 02 9955 3640
Mob: 0404 852 537


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

a tag layer on cvs

[Matthew Herrmann]

hi all,

what do people think about the idea of a project which sits on top of cvs
and provides another level of abstraction to branching, merging, revision
management etc.

The idea would be to have responsibilities divided up in this hierarchy:

- CHANGELOG (eventually could use TAGSYSTEM to do all the special tag stuff)
- TAGSYSTEM (no magic revision numbers -- all hidden, disallows branching on
individual files, branching automatically creates the branchpoint and branch
tag, allows complex rules for generating diffs, merging generates mergepoint
tags etc., checkouts, tags etc.)
- CVS (revision, tag, logistics of branch management, merging etc.)

TAGSYSTEM would effectively be a system which concretises "best practice"
which is of course another way of saying "magical rules which much be obeyed
so things work as expected". The reality is that CVS can do basically
everything that other systems like clearcase can, with the exception of
graceful directory and file renames, only, people need to do things "the
right way". This would remove that "right way" element. It would become a
"command".

CVS then no longer needs to concentrate on providing user interface type
features, it basically operates as a versioned file management system.
Instead of every shop making their own custom scripts to do things, there is
a 'recommended' shell which does what most people do anyway -- mergepoint
tags etc.

My idea was to do it in a compilable scripting language, (python -- my
choice, perl, vb (just kidding)) and that it would call cvs behind the
scenes.

is this way off? or are people interested?

Regards,

Matthew Herrmann
--
Far Edge Technology
Level 11, 80 Mount St
North Sydney NSW 2060
Australia

Ph: 02 9955 3640
Mob: 0404 852 537


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

request for log option to specifically exclude the first tag, workaround for cvs log -r -r

[Matthew Herrmann]

Hi all,

I think this topic has not been given enough discussion, namely the problem
that it is *impossible* through using standard CVS commands to get the log
messages _taking_ one from a tag to another tag. This thread got dropped a
while ago by people quietly whispering "oh well, it can't be done" and
others saying "well it does work, read the newsgroup" without trying it. All
of the log -rR1::R2 -rR2 etc. style methods all fail in at least some cases,
especially when there has been no change to a file over two tags, so a
revision number is tagged with both tags (try it!)

I think if anything, this is a feature which deserves to be added to the new
dev version, as opposed to emacs support or what have you... I was amazed it
hasn't been come across before.

Anyway, enough rant, I think I may have found a pragmatic workaround that
recent discussions about dates inspired me on: find the dates of the two
logs, and then do a cvs log from just after the last committed date/time of
the first tag, and up to and including the date/time of the last file
containing the second tag. But that won't be sufficient if you're using
branching -- you'll then need to ensure that you're only getting log
messages from the branch containing both tags. I haven't implemented it yet,
but ... agh!

i think this would be how it works (not tested):
run perl/python script to get dates of both tags
find maxs/mins
and feed these into:
cvs log -d"DATE1TAG2

since it would be used pretty commonly -- shame -rTAG1::TAG2 doesn't do what
people would expect it to do.

Regards,

Matthew Herrmann
--
Far Edge Technology
Level 11, 80 Mount St
North Sydney NSW 2060
Australia

Ph: 02 9955 3640
Mob: 0404 852 537


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

Import new option -o include in modules file

[Matthew Herrmann]

Hi guys,

I've had an idea to resolve the cvs ls issue: introduce a new option -o
which adds a default entry to the modules file upon import:

import -o proj faredge start

Then, people could put that in their .cvsrc files and you could guarantee
that cvs co -c would give a true list of the repo's contents. Also a new
user doesn't have to learn about the admin files straight away (and possibly
shouldn't unless they're the cvs admin).

Comments welcome.

Matthew Herrmann


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

getting changes between two release tags

[Matthew Herrmann]

Hi,

I've read the discussions recently on this matter, and the suggesitions
don't seem to apply to this case:

Is there any way to get log information with the specific criteria:

show logs:
where revision number > tag for old revision number and <= new revision
number

If the revision numbers are the same, I don't want to see the tag.

Specifically this is to answer the question "what changes have been made to
go from release A to release B?"

If I use -rA::B, I don't get the last revision made to each file, ie. from
1.2.1.23 to 1.2.1.24, I lose the 1.2.1.24 revision. If I use -rA:B, I get a
revision listed for 1.2.1.23 to 1.2.1.23 which is wrong because the software
didn't change between releases. If I use -rA::B -rB I get a similar problem.

I'd rather not parse it through a script (ie. I'd rather get CVS to do it
directly), although I do have perl installed.

Thanks in advance for any advice.

Regards,

Matthew Herrmann
---
Far Edge Technology

tel: +612 9955 3640

11/80 Mount St
North Sydney NSW 2060
Australia


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

RE: implementing basic metadata in cvs using tags

[Matthew Herrmann]

Hi Paul, (and Greg),

Thanks for your comments. The main idea was to wrap CVS in another layer of
script which would invisibly filter out the tag information. I agree that it
would be messy to use tags in the long run.

I think your suggestion sounds like a good one of adding info to RCS works,
since compatibility with that product is a non-issue for me.

These thoughts came to my mind as I saw the meta-information support in
Subversion and I looked for a way to integrate these into CVS (just mainly
interest related, not out of a burning need for a feature immediately).

Arguably it _is_ for a build system to register libraries etc., but as I
work in interpreted languages where the compilation is usually incremental
(check out libraries+source, work on interpreted source using compiled
libraries, compile everything for deployment), a 'build' system as such
except for the specific case of deployment doesn't really make sense, since
you usually compile about 20% of it.

I would still like to tie 3rd-party operations into checking out files
automatically, if possible. Can this be done using the existing admin files?

Regards,

Matthew Herrmann
---
Far Edge Technology

tel: +612 9955 3640

11/80 Mount St
North Sydney NSW 2060
Australia

-Original Message-
From: Paul Sander [mailto:[EMAIL PROTECTED]]
Sent: Sunday, 14 October 2001 19:09
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: implementing basic metadata in cvs using tags


Do you really believe that overloading symbolic tags is a good idea?
What value do you set the special tags to?  Are users allowed to modify
them with the usual tag commands?  Do you want users to see them with the
usual log commands?  Do you want to prevent users from using them as
version selectors during checkout?  How do you guarantee that existing
tags won't happen to collide with newer special ones?

I believe that if you're going to the trouble to modify CVS to interpret
tags specially, then you may find that it's just as easy (perhaps easier)
to modify the RCS library to provide a general interface to per-file and
per-revision newphrases.  If this indeed is true, then there's little to be
gained from trying to bend an existing structure to a purpose for which
it's not intended.

Keep in mind also that great care must be taken in what kind of metadata
are stored.  Stuff that's not directly related to version control should
be left to the build system.  The COM stuff that you describe, for
example, might be best left to the build system.  Be wary of any post-
processing that would be needed if it's not directly related to getting
files in and out of the repository.  Unpacking tar files is on thing;
registering libraries with the OS is another.  Setting permissions is
little stickier; it's useful to have an interface to set permissions
as appropriate to the user performing the checkout (e.g. giving
execute permissions to executable programs), but complete access
control (e.g. the exact ownerships and modes on a Unix system) are
arguably outside the scope of the version control system and they're
too tied to the platform to be useful generally.

--- Forwarded mail from [EMAIL PROTECTED]

I just had a thought while reading people's emails about renames and
preserving unix permissions and so on, and an idea hit me:

why not have registered programs on the client side which mangle permissions
and so on into a sort of UUencoded string, put into a file's tag, which is
then read by the same program and reapplied when the file is checked out?

Here's the sketch of where you could use it and what you could do:

Example:
file has group read, group write, world read, world execute. Then, by some
mechanism, you specify that a given file is enabled for this form of tag
mangling. upon performing a commit, the client program GETPER say would read
the permissions, then encode them as XMKJ1J. That one file gets given the
tag "META_GETPER_XMKJ1J". When the file is checked out, the checking out
procedure knows by the magic "META_" that it needs to invoke the external
program on that file. It runs "GETPER" and passes it as a parameter the
filename and XMKJ1J. That program knows what to do with it and does so.

Example:
OCX and COM DLLs used in application may change as the application goes. As
an input to the project, they should be included so that you don't trash
your machines, re checkout your source and then not be able to compile
because they're missing. With this method, you could give them a "sticky
tag" called "COM_REGISTER", which then evokes an external program on
checkouts/updates and releases, appropriately registering and unregistering
the COM file. Maybe even database files could be attached/detached using a
similar mechanism? (not sure if this would be useful, but it feels like
there would be oth

implementing basic metadata in cvs using tags

[Matthew Herrmann]

Hi people,

I just had a thought while reading people's emails about renames and
preserving unix permissions and so on, and an idea hit me:

why not have registered programs on the client side which mangle permissions
and so on into a sort of UUencoded string, put into a file's tag, which is
then read by the same program and reapplied when the file is checked out?

Here's the sketch of where you could use it and what you could do:

Example:
file has group read, group write, world read, world execute. Then, by some
mechanism, you specify that a given file is enabled for this form of tag
mangling. upon performing a commit, the client program GETPER say would read
the permissions, then encode them as XMKJ1J. That one file gets given the
tag "META_GETPER_XMKJ1J". When the file is checked out, the checking out
procedure knows by the magic "META_" that it needs to invoke the external
program on that file. It runs "GETPER" and passes it as a parameter the
filename and XMKJ1J. That program knows what to do with it and does so.

Example:
OCX and COM DLLs used in application may change as the application goes. As
an input to the project, they should be included so that you don't trash
your machines, re checkout your source and then not be able to compile
because they're missing. With this method, you could give them a "sticky
tag" called "COM_REGISTER", which then evokes an external program on
checkouts/updates and releases, appropriately registering and unregistering
the COM file. Maybe even database files could be attached/detached using a
similar mechanism? (not sure if this would be useful, but it feels like
there would be other similar uses).

Example:
Well, potentially (this would be a wrap over the top of cvs) -- you could
automatically record in a similar format the changes of filenames and then
have it intercept log commands to detect when filenames change.

Ie. it would store a tag at the point of the creation of the new file which
links back to the old file. cvs log is intercepted and generated for both
files. they are then somehow concatenated.

i recognise this is a much bigger problem but this feature could be a useful
stepping stone to getting that working.

Forces as I see it are:
- need sticky tags to exist in a non-branch context. I don't know if this
can be done? If so, then it's simple, I just add an appropriate IS-A tag to
a file, and then the appropriate programs are evoked at different points. If
this is unavailable, then the only practical way to say "this file's unix
permissions need to be tracked" is to either have some sort of per-module
list of files to operate on, or to say for example "all html files need to
have permissions tracked". We then say that "permissions tracked" means call
"GETPER" before commits to generate magic tags.

- check points where code could run before commits and so on. if this is
done as a patch, then this would be the way to go. if not, then this is not
necessary since the more messy 'wrap cvs' technique applies.

- need to be able to check the tags on checked out files in CVS. i think
this is available via cvs log but please let me know if i'm wrong

- need tags to be basically constant-time efficiency. a lot of this metadata
will get generated, so if it clags cvs then this approach won't work.


Could people please:
1. Suggest if there's a better way to solve the COM registration problem? I
remember something about the commitinfo and modules files specifying
applications to run... ? My offline copy of the cvs manual is broken so i
can't look it up.

2. Can I do this just by using built-in functionality or would I need to
patch or wrap?

3. Is this useful? It seems to me to solve the whole metadata problem -- you
can store file permissions for different platforms and other random
information that may be required.

People's comments would be greatly appreciated.

Regards,

Matthew Herrmann
---
Far Edge Technology

tel: +612 9955 3640

11/80 Mount St
North Sydney NSW 2060
Australia


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

wincvs/samba problem

[Matthew Herrmann]

Hi Phil,

we recently set up cvs network using samba and win2k clients and we found
the problem was because when of different readonly flag behaviour in windows
and linux.

If I Matthew set something to readonly in linux, someone else isn't allowed
to turn it off, but in windows that's not the case. So files you commit to
the server can't be un-readonly'ed by someone else, hence the problem.

The proper solution is not to use it over a file system (we haven't done
this yet), but in the interim we set up a chron job which runs every minute
to turn off all the read only flags in the repository.

this has been working fine for us but YMMV.

regards,
matt herrmann
far edge technology


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

change date of a commit

[Matthew Herrmann]

Hi people,

this one's a particularly straightforward one (except it might be
impossible).

basically, we are using a network file-based system (as opposed to
client/server, with win2k clients, linux server). Anyway, one of the
computers had the date wrong by 2 months when something was committed so
there's now some entries for 26 August instead of 26 June. Since the dates
are to be used for an automatic versioning system, this is going to be a
thorn in my side. Is there some way I can do this safely? If not, is there
some dodgy way I can do it? (I mean I can back up the CVS directory and just
copy it back if I stuff it up)

One approach I have considered is search/replace in multi-document editor
for 2001.08.27 etc. but I'm worried about caning something else in the
process. Needless to say I'm moving soon to a client/server model to avoid
this and similar issues.

I'm using Windows 2000 without awk and other such 3-letter worded tools
unfortunately.

btw, the utility i need this for is a small vb thing which parses the output
from cvs log into:

cvs log > changes.log
parselog changes.log

generates:
26/07/2001
- updated blah (Author: Joe Bloggs Branch: DOC_MGR_4_1_PATCHES)
- other commit (Author: Joe Bloggs Branch: faredge)
- other commit (Author: Eric Smythes Branch: faredge)
- yet another commit (Author: Joe Bloggs Branch: DOC_MGR_4_1_PATCHES)

27/07/2001
- wefoij (Author: Joe Bloggs Branch: DOC_MGR_4_2_PATCHES)

which we needed for something a human could read to answer the question
"what have you guys changed in the past week"? Optionally, it can list which
files were changed in a given commit (it exploits uniqueness of commit
comment on a given day -- one would hope!! 'made changes' :-( ) If anyone
needs it let me know and I'll email it to them, (it needs vb runtimes
installed) or if this already existed and I reinvented the wheel please let
me know so I can use that instead. For us anyway there was a glaring need
and I'd be amazed if I was the first to need such a feature.

Thanks for any help,

Matthew Herrmann
Far Edge Technology


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

to branch or not to branch

[Matthew Herrmann]

Hi all,

I've just begun version control for one of my clients. We make releases
every couple of weeks to customers, and sometimes, restructuring of objects
etc. means that bug fixes are better off being made to the version a client
was given rather than giving them the more unstable current dev version. I
don't get the feeling this is particularly unusual.

I'm tagging all the modules just before we release with:
cvs rtag -b ROT_major_minor_build mod1 mod2 ...

The question is, should I use the -b option even if I don't need to branch
yet? I know there a size+speed+complexity overhead associated. Most of the
time it doesn't happen, but I want to have the option open if it's needed.
Can I just tag it and then later turn it into a branch?

Any help would be greatly appreciated.

Regards,

Matthew Herrmann
Far Edge Technology


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