Eric Siegerman wrote:
I haven't experienced any flakiness -- at least not with recent
versions; it was worse in the past. But then, I haven't put any
large binaries into CVS, so I wouldn't know about that.
The only flakiness I've noticed with large binaries is that if you do an
import of a
The algorithm that CVS and RCS use to identify the ancestor is pretty
simple: Scanning the version numbers of the contributors, find the
longest common prefix with respect to the component numbers. If the
merge were to augment the CVS metadata to enable shortening the distances
between the
On Thu, Apr 12, 2001 at 08:34:33AM -1000, Joseph Dane wrote:
"Mike" == Mike Castle [EMAIL PROTECTED] writes:
Mike As I said in an earlier post, this can be scripted around.
can you give me an idea as to what such a script might look like?
wouldn't there have to be some sort of 'database'
. Any idea what
the actual command might be?
Thanks,
Keith Hearn
-Original Message-
From: Mike Castle [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 13, 2001 10:42 AM
To: [EMAIL PROTECTED]
Subject: Re: CVS bashing?
On Thu, Apr 12, 2001 at 08:34:33AM -1000, Joseph Dane wrote
Keith Hearn writes:
Below, one of the commands you say to run is "cvs tags". I don't think
that's right. At least, it's not documented in Cederqvist, and it's not
implemented in my version 1.10.7. As you said, it's been a while since you
used cvs, so I suspect you've got the command name
--- Forwarded mail from [EMAIL PROTECTED]
On Wed, Apr 11, 2001 at 05:21:26PM -0700, Paul Sander wrote:
- The *info files accept a comprehensive list of sources on their command
lines, limiting their scalability. (After a branch merge on a very large
project, the command line buffer of
On Wed, 11 Apr 2001 [EMAIL PROTECTED] wrote:
There are obviously some areas where CVS can be improved - no doubt.
But if you compare it to some other commercial SCM system that I'm
familiar with, e.g. ENVY that comes with IBM's Visual Age for Java or
PVCS, it is much, much superior. If
: Wednesday, April 11, 2001 3:58 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: CVS bashing?
There are obviously some areas where CVS can be improved - no doubt.
But if you compare it to some other commercial SCM system that I'm
familiar with, e.g. ENVY that comes with IBM's Visual Age
[EMAIL PROTECTED] on 2001.04.11 21:31:01
On Wed, Apr 11, 2001 at 06:06:22PM -0700, Paul Sander wrote:
- Invoke a type-specific merge tool, ideally one of the user's choice.
Actually, simply "an external tool. Period" would be sufficient. Then
said external tool can have whatever
On Thu, Apr 12, 2001 at 11:05:51AM -0400, Noel L Yap wrote:
If a wrapper tool were used, it would necessarily have to munge around the
CVS/Entries file which is supposed to be internal to CVS (eg its implementation
could change or it could disappear altogether in the future).
Huh?
I thought
[EMAIL PROTECTED] on 2001.04.12 11:14:55
On Thu, Apr 12, 2001 at 11:05:51AM -0400, Noel L Yap wrote:
If a wrapper tool were used, it would necessarily have to munge around the
CVS/Entries file which is supposed to be internal to CVS (eg its
implementation
could change or it could disappear
It would not be necessary for the merge tool itself to muck around with
CVS metadata. Just have CVS do that and invoke an external tool to perform
the actual work of the merge.
--- Forwarded mail from [EMAIL PROTECTED]
[EMAIL PROTECTED] on 2001.04.11 21:31:01
On Wed, Apr 11, 2001 at 06:06:22PM
On Thu, Apr 12, 2001 at 11:29:59AM -0400, Noel L Yap wrote:
[EMAIL PROTECTED] on 2001.04.12 11:14:55
I thought we were talking about a generic tool that would do a merge for
any arbitrary file and save it to disk. What needs to use CVS/Entries?
Should CVS be told about the merge?
Ahhh.
[EMAIL PROTECTED] on 2001.04.12 13:31:41
On Thu, Apr 12, 2001 at 11:29:59AM -0400, Noel L Yap wrote:
[EMAIL PROTECTED] on 2001.04.12 11:14:55
I thought we were talking about a generic tool that would do a merge for
any arbitrary file and save it to disk. What needs to use CVS/Entries?
"Mike" == Mike Castle [EMAIL PROTECTED] writes:
Mike On Wed, Apr 11, 2001 at 06:06:22PM -0700, Paul Sander wrote:
- If a branch is merged multiple times to an ancestor, don't count
the result of the prior merge as a conflict. (Remember, CVS
performs a
Mike As I said in an earlier
[EMAIL PROTECTED] on 2001.04.12 14:34:33
"Mike" == Mike Castle [EMAIL PROTECTED] writes:
Mike On Wed, Apr 11, 2001 at 06:06:22PM -0700, Paul Sander wrote:
- If a branch is merged multiple times to an ancestor, don't count
the result of the prior merge as a conflict. (Remember, CVS
Someone brought up a site on another mailing list about CVS and its
limitations and was citing this as a reason to not use CVS...what do you
all think about this? Some of this stuff I have personally witmessed
(i.e. large binary file problem, no directory versioning) but I'm
curious as to
...
Chuck
-Original Message-
From: gary.heuston [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 11, 2001 1:04 PM
To: info-cvs
Subject: CVS bashing?
Someone brought up a site on another mailing list about CVS and its
limitations and was citing this as a reason to not use
CVS
On Wed, Apr 11, 2001 at 01:04:28PM -0500, Gary Heuston wrote:
Someone brought up a site on another mailing list about CVS and its
limitations and was citing this as a reason to not use CVS...what do you
all think about this? Some of this stuff I have personally witmessed
(i.e. large binary
On Wed, Apr 11, 2001 at 04:44:49PM -0400, Eric Siegerman wrote:
Merging is very primitive
Hmmm. How could it be better? NOT a rhetorical question; I'd
really like to know. (I haven't used the commercial ones he's
comparing CVS to.)
I've recently started working at a perforce shop.
On Wed, Apr 11, 2001 at 06:06:22PM -0400, Eric Siegerman wrote:
On Wed, Apr 11, 2001 at 02:27:15PM -0700, Mike Castle wrote:
I've recently started working at a perforce shop. One thing that perforce
does with it's merging is, instead of doing a default merge, it gives you
options:
From: Mike Castle [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 11, 2001 2:27 PM
I've recently started working at a perforce shop. One thing
that perforce
I worked with perforce for a while, and there are a couple of other things I
miss, besides the merge options.
o Atomic changes. It's
All of the points made in that page are right on. I can go on to say more:
- The modules database isn't versioned, which can affect reproducibility
requirements.
- The *info files accept a comprehensive list of sources on their command
lines, limiting their scalability. (After a branch
BTW, there's now a stripped-down version of ClearCase, suitable for
for small workgroups, for a much cheaper price. It's called ClearCase
LT, and you can get more info on it from
http://www.rational.com/products/clearcase/ .
--- Forwarded mail from [EMAIL PROTECTED]
There are obviously some
On Wed, Apr 11, 2001 at 05:21:26PM -0700, Paul Sander wrote:
- The modules database isn't versioned, which can affect reproducibility
requirements.
This same problem exists with Perforce and it's concepts of 'views' (think
each user has their own modules files).
What we do is, instead of
25 matches
Mail list logo
