/listinfo/info-cvs
--
Paul Sander | Lets stick to the new mistakes and get rid of the
old
[EMAIL PROTECTED] | ones -- William Brown
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
this to happen.
Is there some way to prevent cvs from writing anything to the file?
Separate or change the case of $Id$. Something that looks like
'$I d$' or '$id$'.
You might also look into what cvs admin -ko and cvs admin -kk can
do for you.
--
Paul Sander | Lets stick to the new
, 2005, at 7:08 AM, [EMAIL PROTECTED] wrote:
Paul Sander wrote:
Be careful here. The location appears to the directory
identified by
the client at the time the edit was done. Due to network
mounts, this
path is not unique. So when editing, unediting, or
committing a file,
there's really no way
of
these
days, when I have the time, I'm going to work on implementing rwatch
and
redit commands, with options to specify the user.
--
Paul Sander | When a true genius appears in the world, you may
[EMAIL PROTECTED] | know him by this sign: that all the dunces are in
| confederacy
.
--
Paul Sander | To do two things at once is to do neither
[EMAIL PROTECTED] | Publilius Syrus, Roman philosopher, 100 B.C.
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
If you have direct access to your repository, then take a look at the
rinfo program, which produces such output in a way that's easy to scan
automatically. Otherwise, you'd be well advised to learn awk or perl,
which are good at scanning complex output like this.
The rinfo program is located at:
+gUDoMCbF0zjgmStBJIT9gCfUU83
K/TZMZdXbJx+BWVFaXGS0Jk=
=fz6n
-END PGP SIGNATURE-
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
--
Paul Sander | When a true genius appears in the world, you may
[EMAIL
, an algebra can be easily written to manipulate such lists.
Combine this with a way to link these lists with your defect tracking
system, and you have the tools to build a very good change control
system.
--
Paul Sander | Lets stick to the new mistakes and get rid of the
old
[EMAIL
approaches?
--
Paul Sander | Lets stick to the new mistakes and get rid of the
old
[EMAIL PROTECTED] | ones -- William Brown
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
, however.
--
Paul Sander | Lets stick to the new mistakes and get rid of the
old
[EMAIL PROTECTED] | ones -- William Brown
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
trigger useful?
--
Paul Sander | When a true genius appears in the world, you may
[EMAIL PROTECTED] | know him by this sign: that all the dunces are in
| confederacy against him. -- Jonathan Swift,
writer.
___
Info-cvs mailing
.
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
--
Paul Sander | When a true genius appears in the world, you may
[EMAIL PROTECTED] | know him by this sign: that all the dunces are in
| confederacy
but not culture,
sex but not love, and amusements but not happiness.
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
--
Paul Sander | To do two things at once is to do neither
[EMAIL PROTECTED] | Publilius
a compononet. How will I undo this
checkout. Removing lock manually is one option but is there any other
better way to do this.
--
Paul Sander | When a true genius appears in the world, you may
[EMAIL PROTECTED] | know him by this sign: that all the dunces are in
| confederacy
://lists.gnu.org/mailman/listinfo/info-cvs
--
Paul Sander | To do two things at once is to do neither
[EMAIL PROTECTED] | Publilius Syrus, Roman philosopher, 100 B.C.
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info
, add all in HEAD to new folder, grab endpoints on branches, add
all
branches as I best can).
Regards,
Jesper Vad Kristensen
Aarhus, Denmark
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
--
Paul Sander
.
This appears to be a case where adding support for external
datatype-specific diff and merge tools would be useful.
--
Paul Sander | Lets stick to the new mistakes and get rid of the
old
[EMAIL PROTECTED] | ones -- William Brown
___
Info-cvs mailing
co -rAPPLICATION_1_0_0_3 A B,
why do I get some extra directories and sources that where not
explicitly tagged (e.g. B/otherDir)
--
Paul Sander | Lets stick to the new mistakes and get rid of the
old
[EMAIL PROTECTED] | ones -- William Brown
Interesting. Just before invoking cvs tag, can you confirm that B/otherdir
is not in your workspace? Does the output of cvs tag give any indication
of what it's doing at the time it applies the tag to B/otherdir?
--- Forwarded mail from [EMAIL PROTECTED]
On Wed, 9 Feb 2005 11:23:52 -0800, Paul
CVS can't handle it. For each file, you must identify the file/version
pairs for the common ancestor and two contributors, get them all into your
workspace, invoke diff3 with the proper incantation, and commit the result.
--- Forwarded mail from [EMAIL PROTECTED]
Lets say I have the following
file with identical content was
added to a new location.
Gee, Greg, how much version control capability do you really want to
offload from CVS?
--
Paul Sander | Lets stick to the new mistakes and get rid of the
old
[EMAIL PROTECTED] | ones -- William Brown
On Feb 5, 2005, at 12:47 PM, [EMAIL PROTECTED] wrote:
[ On Thursday, February 3, 2005 at 00:29:31 (-0800), Paul Sander
wrote: ]
Subject: Re: 'cvs add' client/server semantics (was Re: Triggers)
Many shops seem to think that it's reasonable to allow users to commit
code only after it has
On Feb 2, 2005, at 12:53 PM, [EMAIL PROTECTED] wrote:
[ On Wednesday, February 2, 2005 at 03:35:48 (-0800), Paul Sander
wrote: ]
Subject: Re: 'cvs add' client/server semantics (was Re: Triggers)
Committing empty files may not be permitted by project policy.
Straw man!
(and a B.S. policy if I've
On Feb 1, 2005, at 8:16 AM, [EMAIL PROTECTED] wrote:
Paul Sander [EMAIL PROTECTED] writes:
On Jan 31, 2005, at 9:30 AM, [EMAIL PROTECTED] wrote:
That's not to say that we will *always* know at add time that the
commit will fail; failures can occur due to problems in their
content
which
On Feb 1, 2005, at 12:13 PM, [EMAIL PROTECTED] wrote:
[ On Sunday, January 30, 2005 at 16:45:35 (-0800), Paul Sander wrote: ]
Subject: Re: Triggers (was Re: CVS diff and unknown files.)
It's not so unusual for people who have done SCM for many years on
large and varied projects.
Well it depends
On Feb 1, 2005, at 12:03 PM, [EMAIL PROTECTED] wrote:
[ On Saturday, January 29, 2005 at 15:22:34 (-0800), Paul Sander
wrote: ]
Subject: Re: Triggers (was Re: CVS diff and unknown files.)
You don't seem to understand the fact that cvs add and cvs rm are
supposed to be exactly the same as vi
to control every
keystroke. I just want to keep them on the path they've agreed to
take, because it's easier to stay there than to wander off and find the
way back.
--
Paul Sander | To do two things at once is to do neither
[EMAIL PROTECTED] | Publilius Syrus, Roman philosopher, 100 B.C
operation. The reason is because
there's more to it than linking together partial logs as Greg claims.
There are also issues relating to branch management, like deciding
which RCS file version 1.2.1.3 comes from.
--
Paul Sander | To do two things at once is to do neither
[EMAIL PROTECTED
(and apparently Greg)
believe is not appropriate.
--
Paul Sander | Lets stick to the new mistakes and get rid of the
old
[EMAIL PROTECTED] | ones -- William Brown
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info
On Feb 1, 2005, at 2:51 AM, [EMAIL PROTECTED] wrote:
Paul Sander [EMAIL PROTECTED] writes:
Would you post a message stating your point of view, completely,
please? Thanks!
I need a way to generate 'cvs diff' against read-only repository. To
achieve this it's enough to fix 'cvs add' so
On Jan 30, 2005, at 10:24 PM, [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Sander [EMAIL PROTECTED] writes:
Wait a second. The OK for addition, but wrong for commit is exactly
the status quo. The cvs add command succeeds, cvs commit fails
due to commitinfo. What
enforcement
at the moment the violation occurs.
--
Paul Sander | To do two things at once is to do neither
[EMAIL PROTECTED] | Publilius Syrus, Roman philosopher, 100 B.C.
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman
On Jan 30, 2005, at 3:28 AM, [EMAIL PROTECTED] wrote:
Paul Sander [EMAIL PROTECTED] writes:
On Jan 28, 2005, at 11:36 AM, [EMAIL PROTECTED] wrote:
[...]
If you consider my suggestion, there will be no such a beast as
add-to-working-copy-time trigger. The commit trigger will notice the
file is new
On Jan 30, 2005, at 3:42 AM, [EMAIL PROTECTED] wrote:
Paul Sander [EMAIL PROTECTED] writes:
On Jan 28, 2005, at 9:34 AM, [EMAIL PROTECTED] wrote:
Sergei Organov wrote:
Paul Sander [EMAIL PROTECTED] writes:
On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote:
If cvs add will only warn about
On Jan 30, 2005, at 6:40 AM, [EMAIL PROTECTED] wrote:
Paul Sander [EMAIL PROTECTED] writes:
On Jan 28, 2005, at 8:50 AM, [EMAIL PROTECTED] wrote:
Paul Sander [EMAIL PROTECTED] writes:
On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote:
[...]
Just to understand your point better, do you propose
really don't see how CVS can help you.
As critical as I am about CVS, I really have only 3 or 4 really hot
buttons about it. Triggers happen to be one of them. :-)
--
Paul Sander | Lets stick to the new mistakes and get rid of the
old
[EMAIL PROTECTED] | ones -- William Brown
On Jan 28, 2005, at 8:50 AM, [EMAIL PROTECTED] wrote:
Paul Sander [EMAIL PROTECTED] writes:
On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote:
[...]
Just to understand your point better, do you propose 'cvs add -c
new_file' and 'cvs ci new_file' run exactly the same set of triggers?
Different
On Jan 28, 2005, at 9:34 AM, [EMAIL PROTECTED] wrote:
Sergei Organov wrote:
Paul Sander [EMAIL PROTECTED] writes:
On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote:
If cvs add will only warn about the problems, -- that's
OK with me as a user.
Actually, the way I see the situation is it only
On Jan 28, 2005, at 11:36 AM, [EMAIL PROTECTED] wrote:
Todd Denniston [EMAIL PROTECTED] writes:
Sergei Organov wrote:
Paul Sander [EMAIL PROTECTED] writes:
On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote:
[...]
Just to understand your point better, do you propose 'cvs add -c
new_file
On Jan 28, 2005, at 3:55 PM, [EMAIL PROTECTED] wrote:
[ On Friday, January 28, 2005 at 03:26:05 (-0800), Paul Sander wrote: ]
Subject: Triggers (was Re: CVS diff and unknown files.)
Sigh. Just because you haven't found a use for add-time triggers
within the scope of your blinders, doesn't mean
On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote:
Paul Sander [EMAIL PROTECTED] writes:
[...]
What register adds in the repo nonsense are you talking about? The
proposal I made simply requires a contact with the server to run the
add-time triggers; it does NOT require add-time modifications
On Jan 27, 2005, at 12:36 PM, [EMAIL PROTECTED] wrote:
[ On Wednesday, January 26, 2005 at 21:05:46 (-0800), Paul Sander
wrote: ]
Subject: Re: CVS diff and unknown files.
See above. If there are no add-time triggers, then I can live with
what you say. On the other hand, some shops REQUIRE add
'
command. As for the second case, I think that without '-c' cvs should
tag the file (either silently or issuing a warning), and with '-c' it
should abort the whole operation.
I don't believe that these issues have been considered as part of
either cvs add proposal.
--
Paul Sander | To do
On Jan 26, 2005, at 11:06 AM, [EMAIL PROTECTED] wrote:
[ On Wednesday, January 26, 2005 at 01:01:55 (-0800), Paul Sander
wrote: ]
Subject: Re: CVS diff and unknown files.
You're falling into the same trap that Greg does, which is to think
that the way CVS works today is the way that it simply
or not it will stay. The requirement to supply add-time triggers has
been identified (by a number of users), which requires a contact with
the server. This has undergone some heated debate.
--
Paul Sander | Lets stick to the new mistakes and get rid of the
old
[EMAIL PROTECTED] | ones
These are not valid reasons. Here's why:
- ClearCase MVFS is a filesystem that offers the same access to Unix
tools as any other filesystem. They need not be ported to specialized
environments to run under ClearCase.
- ClearCase clients are available on several flavors of Unix, including
On Nov 29, 2004, at 8:53 AM, [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike [EMAIL PROTECTED] writes:
I have a director asking why I don't want to user the company's
clear case server. One item I mentioned is the lack of integration
into unix tools and the lack of a
People do, but in most cases it's not considered best practice. If you
can reproduce the binaries from source, then don't put them under CVS;
tag the sources and store the environment in a reproducible way.
If the binaries are not reproducible from source, then there are two
schools of
On Nov 19, 2004, at 10:28 PM, [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Sander wrote:
This is why I hate the -n option of the
checkout/commit/tag/update commands and advocate its removal
from CVS.
What in the world are you talking about??? -n prevents changes
On Nov 19, 2004, at 6:38 AM, [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Sander wrote:
It's simpler, but neither safer nor saner to wrapper script around the
client. The reason is this: If you enforce policy but give the user
an avenue to circumvent it, the user
On Nov 19, 2004, at 6:49 AM, [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Sander wrote:
There is a certain logic to having triggers gate changes to the
repository. There's also a certain logic to having a tool prevent
conditions that will later cause it to fail
On Nov 18, 2004, at 7:38 AM, [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
I still disagree, because some people like working from their laptop
and wireless network connections are hardly ubiquitous yet. Work that
a developer can do from their laptop off of the network can also
--- Forwarded mail from [EMAIL PROTECTED]
[ On Wednesday, November 17, 2004 at 09:19:18 (-0800), Paul Sander wrote: ]
Subject: Re: add hook question (was Re: Problem with importing third-party
sources and adding/committing changes)
It depends on the nature and extent of the changes. I can
--- Forwarded mail from [EMAIL PROTECTED]
[ On Wednesday, November 17, 2004 at 09:46:55 (-0800), Paul Sander wrote: ]
Subject: Re: Problem with importing third-party sources and
adding/committing changes
Paul you keep spreading myths and mistruths. I wish you'd stop.
This is simply
--- Forwarded mail from [EMAIL PROTECTED]
[ On Thursday, November 18, 2004 at 10:38:44 (-0500), Derek Robert Price
wrote: ]
Subject: Re: add hook question (was Re: Problem with importing third-party
sources and adding/committing changes)
Perhaps a -C option to `cvs add' similar to `cvs
--- Forwarded mail from [EMAIL PROTECTED]
Greg A. Woods wrote:
There is no trigger for cvs rm and there MUST _NOT_ be.
There is no trigger for cvs add and there MUST _NOT_ be.
I have to admit, there is a certain logic to drawing the line at
triggers for repository changes, not workspace
--- Forwarded mail from [EMAIL PROTECTED]
Derek Robert Price [EMAIL PROTECTED] writes:
Mark D. Baushke wrote:
Hi Greg,
Is it reasonable to suggest that a addinfo trigger could be run as a
part of the 'cvs commit' command should the client not happen to connect
to the server for a
--- Forwarded mail from [EMAIL PROTECTED]
Paul Sander wrote:
Keep in mind that, although Greg does not acknowledge it, a number
of people in this forum have stated a requirement for an add-time
trigger that could be used for such things as enforcement of naming
conventions and access control
--- Forwarded mail from [EMAIL PROTECTED]
Paul Sander wrote:
It's true that add and commit hooks can enforce the same kinds of policies
as post-conditions of the commit. However, add hooks can enforce things
like naming conventions. I'm working in a shop right now that prefers to
have
--- Forwarded mail from [EMAIL PROTECTED]
[ On Tuesday, November 16, 2004 at 23:53:40 (-0800), Paul Sander wrote: ]
Subject: Re: Problem with importing third-party sources and
adding/committing changes
Keep in mind that, although Greg does not acknowledge it, a number of
people
Keep in mind that, although Greg does not acknowledge it, a number of
people in this forum have stated a requirement for an add-time trigger
that could be used for such things as enforcement of naming conventions
and access control. Such a feature (referred to in the past as
addinfo) would
Don't forget to merge your modules and *info databases. These must be
done by hand.
On Nov 11, 2004, at 3:57 AM, [EMAIL PROTECTED]@dewire.kom wrote:
Ivan Teliatnikov wrote:
Hi there,
Historically I have two CVS repositories located on the same CVS
server.
/opt/cvs/cvs1
/opt/cvs/cvs2
Each
On a file-by-file basis, you can discover the sprout point version number
for any branch. You do this by looking up the RCS magic branch number,
which has the form sprout.0.n where there is always an odd number of
periods.
where sprout is the sprout point version number, and n is the branch
referenced by these virtuals folders / files,
and then they don't have to download module C, this is transparent for
them.
Best Regards,
Paola
Paul Sander wrote:
I think it me who didn't communicate clearly! :-)
The problem you describe appears to be a classic software reuse issue,
in which
--- Forwarded mail from [EMAIL PROTECTED]
Brian Blignaut wrote:
Firstly let me say that if this is not the appropriate place
to ask this question I apologize, I am just not sure where
else to post.
Yes, this is the appropriate place to ask.
I am trying to setup a build process that works
You could add the library to your product modules and build them all at
once. However, I find that a better method is to subject the libraries to
the same kind of control as the rest of the product (with regular builds,
tagging sources, defect tracking and change control, etc.) and provide a
set
I would expect to see errors like this if your CVS server has mounted the
repository over NFS, and the NFS server rebooted. If this is indeed the
case, then you must unmount the NFS partition on your CVS server, then
re-mount it. (Rebooting the CVS server might be easier.) You might also
wouldn't have duplicated libraries' code in the projects that are
sharing them. And when I upgrade the libraries (i.e. when a new release
appears) I would have to do it only once.
I'm not sure if CVS has this feature, I'm only asking if any of you has
done this before or knows how to do it.
Paul
--- Forwarded mail from [EMAIL PROTECTED]
Maarten de Boer wrote:
One catch I can see with this approach is the platform. For
example, our
development platform is Windows using Microsoft Visual
Studio, and our
repository is on a Solaris machine.
So, the testing machine could be
The other thing you should do is avoid using kill -9 as your first resort
to get rid of something you don't want. It's a kill with extreme
prejudice command that blasts the process slot without giving the
application a chance to clean up after itself. Try using ctrl-C, then
just plain kill, then
--- Forwarded mail from [EMAIL PROTECTED]
Ones Self wrote:
Hi,
I'm running a CVS server which compiles and tests the current
files in CVS every hour. I would like to make new checkins
available _only_ if they compile and pass the tests.
So, if a user checks in something which does not
--- Forwarded mail from [EMAIL PROTECTED]
Ones Self [EMAIL PROTECTED] wrote:
I'm running a CVS server which compiles and tests the current
files in CVS every hour. I would like to make new checkins
available _only_ if they compile and pass the tests.
So, if a user checks in something which
Have you considered something like this?
Create a special target in your makefile that performs all the auditing
of your process that you want. Its prerequisites should be all of the
header files you're concerned about. Put it under CVS control and commit it
with all of your sources, and apply
--- Forwarded mail from [EMAIL PROTECTED]
That's why some people call them playpens instead. :-)
Oh, so now we're toddlers who can't even be trusted with sharp instruments.
Hmmm ;-)
Surrounded by nets, noisemakers, and things to pound on...
--- End of forwarded message from [EMAIL
--- Forwarded mail from [EMAIL PROTECTED]
On Wed, Aug 18, 2004 at 05:28:28PM -0400, Jim.Hyslop wrote:
OT rant
Why do people call these sandboxes? I'm a professional software developer,
not a kid playing in the sand.
/OT rant
Hehehe...I think sandbox is a cool term and never thought of it as
Take a look at the CMBoK (CM Book of Knowledge) at http://www.cmcrossroads.com/
and then look for Brad Appleton's wiki of CM patterns, referenced at that
site.
--- Forwarded mail from [EMAIL PROTECTED]
I'm not too sure the last section was a question or a statement, but if
anyone knows of a well
--- Forwarded mail from Greg Woods:
[ On Tuesday, July 6, 2004 at 15:18:50 (-0700), Paul Sander wrote: ]
Subject: RE: binary files bad idea? why?
And BTW, you keep waving over RCS compatability with arguments about
minimum reproducibility that simply do not wash. RCS compatabiltiy
means _all_
--- Forwarded mail from [EMAIL PROTECTED]
[ On Thursday, July 8, 2004 at 23:01:09 (-0700), Mark D. Baushke wrote: ]
Subject: Re: binary files bad idea? why?
IF we assume that the 'cvs update' of a particular file in a user's
sandbox needs to do a three-way merge (checked-out version,
--- Forwarded mail from [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
If you mean you want checkout to record the current timestamp of the
file rather than the time of the checkin, that would also break things
like make.
I'm not sure I follow this. How would using the timestamp of the file
--- Forwarded mail from [EMAIL PROTECTED]
[ On Friday, July 2, 2004 at 12:34:42 (-0700), Paul Sander wrote: ]
Subject: RE: binary files bad idea? why?
--- Forwarded mail from Greg Woods:
It is literally _impossible_ to manually resolve (with any degree of
correctness) any three way merge
--- Forwarded mail from Greg Woods:
[ On Friday, July 2, 2004 at 12:49:58 (-0700), Paul Sander wrote: ]
Subject: RE: CVS corrupts binary files ...
--- Forwarded mail from [EMAIL PROTECTED]
[ On Wednesday, June 30, 2004 at 22:59:27 (-0700), Paul Sander wrote: ]
Subject: RE: CVS corrupts
--- Forwarded mail from Greg Woods:
[ On Friday, July 2, 2004 at 22:25:27 (-0400), Eric wrote: ]
Subject: RE: binary files bad idea? why?
At 2:11 PM -0400 7/2/04, Greg A. Woods wrote:
Why is it so damn hard for everyone to keep this simple fact in mind?
Because it is entirely possible to
--- Forwarded mail from Greg Woods:
It is literally _impossible_ to manually resolve (with any degree of
correctness) any three way merge with conflicts in any ``binary'' file,
regardless of whether it has been encoded as text or not.
It IS possible, using a tools that understand the content of
--- Forwarded mail from [EMAIL PROTECTED]
[ On Wednesday, June 30, 2004 at 22:59:27 (-0700), Paul Sander wrote: ]
Subject: RE: CVS corrupts binary files ...
(A) they're not sources -- they're intermediate product files.
They're not intermediate product files unless they can be reproduced
--- Forwarded mail from [EMAIL PROTECTED]
[ On Monday, June 28, 2004 at 18:31:58 (-0700), Paul Sander wrote: ]
Subject: RE: CVS corrupts binary files ...
On three separate occasions, Greg actually *recommends* intalling and
treating such code drops as uncontrolled sources!
Paul, please stop
--- Forwarded mail from [EMAIL PROTECTED]
[ On Monday, June 28, 2004 at 19:02:19 (-0700), Paul Sander wrote: ]
Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
I have never, ever advocated changing the format of an RCS file in a
way that would break the ci, co, rcs, or rlog
--- Forwarded mail from [EMAIL PROTECTED]
[ On Monday, June 28, 2004 at 14:58:03 (-0700), Mark D. Baushke wrote: ]
Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
Yes, but diff is not diff3. diff is used for the
delta format. diff3 is used by rcsmerge, not for
fundamental
--- Forwarded mail from [EMAIL PROTECTED]
Mark, I agree with your response to Greg's claims about RCS
compatibility, or the lack thereof.
In particular, I am not aware of any fundamental
problems rcs 5.7 will have if someone were to
introduce a new keyword which would name a program
other than
--- Forwarded mail from [EMAIL PROTECTED]
[ On Monday, June 28, 2004 at 01:44:36 (-0700), Mark D. Baushke wrote: ]
Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
The RCS format is very extensible and in fact the
CVSNT folks have extended it already and I have had
no problems
--- Forwarded mail from [EMAIL PROTECTED]
Paul Sander [EMAIL PROTECTED] writes:
--- Forwarded mail from [EMAIL PROTECTED]
=20
Rather than use a hint to expose an
implementation detail, I suggest recording a
data type instead. Maybe even a MIME type. Then
provide a suitable mechanism to map
--- Forwarded mail from [EMAIL PROTECTED]
[ On Monday, June 28, 2004 at 11:00:23 (-0400), Jim.Hyslop wrote: ]
Subject: RE: CVS corrupts binary files ...
Any manual procedure is prone to error. I prefer to automate things as much
as possible, to minimize the possibility of human error. Any
--- Forwarded mail from [EMAIL PROTECTED]
[ On Thursday, June 17, 2004 at 15:49:39 (-0700), Paul Sander wrote: ]
Subject: RE: CVS corrupts binary files ...
Nope, I got it. The thing is, you can control pointers (e.g. makefiles
containing references to files stored in a library somewhere) all
--- Forwarded mail from Greg Woods:
[ On Thursday, June 17, 2004 at 16:49:42 (-0700), Paul Sander wrote: ]
Subject: Smoke, FUD (was Re: CVS corrupts binary files ...)
If this is true, then we're in violent agreement. But to date, you have
argued that making the necessary changes to CVS
Normally one would apply a tag to the versions that are ready for testing,
and update the tag as bugs are fixed. Then apply a second tag to the
code that reaches production quality. To apply the second tag, use the
cvs rtag -r option.
The bummer with this is that if you make bug fixes in your
--- Forwarded mail from [EMAIL PROTECTED]
Don Butts wrote:
I asked this question last Friday but got no response.
Was it poorly asked, not enough information, too ignorant for
words?
I wouldn't remove the branches. I'm always reluctant to remove anything from
the history.
Instead of
--- Forwarded mail from [EMAIL PROTECTED]
Jean-Christian Imbeault wrote:
One of our developers just checked in new code (more than
once) and by mistake renamed a directory from src to source.
Is there a simple way to undo this? I've been reading the
archives and it seems that there isn't
I think there are two aspects to the removing sticky tags issue:
- Removing tags
- Removing the stickiness of tags
Removing tags is desirable to clean up the output of cvs log if a lot
of temporary tags are created. An example of this is when built sources
are labelled after every build, and
--- Forwarded mail from [EMAIL PROTECTED]
On Thu, 17 Jun 2004, Feldmann, Rick wrote:
Date: Thu, 17 Jun 2004 11:53:55 -0400
From: Feldmann, Rick [EMAIL PROTECTED]
To: 'Kaz Kylheku' [EMAIL PROTECTED]
Cc: '[EMAIL PROTECTED]' [EMAIL PROTECTED]
Subject: RE: cvs merging - conflict
Kaz,
--- Forwarded mail from [EMAIL PROTECTED]
[ On Tuesday, June 8, 2004 at 16:21:03 (-0700), Mark D. Baushke wrote: ]
Subject: Re: CVS corrupts binary files ...
It may be that the diff3 algorithm is not always
the best one suited to do such mergers.
That may be true, but the use of the
--- Forwarded mail from [EMAIL PROTECTED]
[ On Wednesday, June 9, 2004 at 09:15:24 (-0400), Jim.Hyslop wrote: ]
Subject: RE: CVS corrupts binary files ...
Let's not throw the baby out with the bathwater, shall we? Granted, CVS was
not *originally* designed to handle binary files. Granted,
1 - 100 of 490 matches
Mail list logo
