>--- Forwarded mail from Greg Woods:
>[ On Friday, July 13, 2001 at 21:19:06 (-0700), Paul Sander wrote: ]
>> Subject: Re: How well does CVS handle other types of data?
>>
>> The existing CVS user model can be maintained without change, even if the
>> merge tool is
[ On Saturday, July 14, 2001 at 14:34:42 (-0700), Mike Castle wrote: ]
> Subject: Re: How well does CVS handle other types of data?
>
> What bug?
>
> CVS used to scan the contents of the conflict file to see if it had been
> fixed. But that was changed to the current method
On Sat, Jul 14, 2001 at 03:48:25PM -0400, Greg A. Woods wrote:
> [ On Saturday, July 14, 2001 at 11:52:48 (-0700), Mike Castle wrote: ]
> > Subject: Re: How well does CVS handle other types of data?
> >
> > Except that CVS doesn't continue to detect conflicts. A simpl
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Saturday, July 14, 2001 at 01:28:12 (-0700), Paul Sander wrote: ]
>> Subject: Re: How well does CVS handle other types of data?
>>
>> And just how is this done? Do you use artifacts of the programming language
>> to
[ On Saturday, July 14, 2001 at 11:52:48 (-0700), Mike Castle wrote: ]
> Subject: Re: How well does CVS handle other types of data?
>
> Except that CVS doesn't continue to detect conflicts. A simple touch(1) of
> the file is sufficient to mark the file as "fixed."
On Sat, Jul 14, 2001 at 02:07:58PM -0400, Greg A. Woods wrote:
> > The existing warning of a conflict during the merge is sufficient to
> > alert the user to a possible problem.
>
> No, it is not. The initial warning is only just that -- an initial
> warning. CVS must now continue to detect tha
[ On Friday, July 13, 2001 at 21:19:06 (-0700), Paul Sander wrote: ]
> Subject: Re: How well does CVS handle other types of data?
>
> The existing CVS user model can be maintained without change, even if the
> merge tool is swapped out with another, such as the trivial selection I
[ On Saturday, July 14, 2001 at 01:28:12 (-0700), Paul Sander wrote: ]
> Subject: Re: How well does CVS handle other types of data?
>
> And just how is this done? Do you use artifacts of the programming language
> to somehow format the marker into something that is not detectable by
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Friday, July 13, 2001 at 20:19:13 (-0700), Paul Sander wrote: ]
>> Subject: Re: How well does CVS handle other types of data?
>>
>> I hope your hack doesn't make it into the general distribution. The
>> comm
[ On Friday, July 13, 2001 at 20:19:13 (-0700), Paul Sander wrote: ]
> Subject: Re: How well does CVS handle other types of data?
>
> I hope your hack doesn't make it into the general distribution. The
> comment makes total sense. The authors have no idea if the conflict
>
[ On Friday, July 13, 2001 at 21:27:27 (-0700), Paul Sander wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> According to your proposal, the user must take at least five steps
> to produce the same result.
I have no idea where you got that from -- but you&#
[ On Friday, July 13, 2001 at 20:42:57 (-0700), Mike Castle wrote: ]
> Subject: Re: How well does CVS handle other types of data?
>
> On Fri, Jul 13, 2001 at 04:03:09PM -0400, Greg A. Woods wrote:
> > [ On Friday, July 13, 2001 at 11:47:27 (-0700), Mike Castle wrote: ]
>
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Friday, July 13, 2001 at 14:57:41 (-0700), Paul Sander wrote: ]
>> Subject: RE: How well does CVS handle other types of data?
>>
>> How so? By giving the hint as stated in the proposal, the user has
>> specified th
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Friday, July 13, 2001 at 12:39:29 (-0400), Steven Rosenstein wrote: ]
>> Subject: Re: How well does CVS handle other types of data?
>>
>> Given all that you've stated below, it seems that the crux of your argument
>
On Fri, Jul 13, 2001 at 04:03:09PM -0400, Greg A. Woods wrote:
> [ On Friday, July 13, 2001 at 11:47:27 (-0700), Mike Castle wrote: ]
> > presenting two versions of the files in question to the user.
>
> Currently CVS does not present to versions of the file to the user.
Yes it does.
I tested i
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Friday, July 13, 2001 at 16:40:47 (-0400), Noel L Yap wrote: ]
>> Subject: Re: How well does CVS handle other types of data?
>>
>> I think this is only partially true. Since CVS doesn't currently absolutely
>> k
[ On Friday, July 13, 2001 at 14:57:41 (-0700), Paul Sander wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> How so? By giving the hint as stated in the proposal, the user has
> specified the desired result. Whether the desired result is the same
> as the
[ On Friday, July 13, 2001 at 16:54:08 (-0500), Cameron, Steve wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> The point of it is that it works as-is for me today. I avoid
> the effort of thinking up, (or copying), implementing, testing,
> backing up,
[ On Friday, July 13, 2001 at 16:30:29 (-0400), Noel L Yap wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> OK, we're getting somewhere. Why not make it preventable (eg via a flag and/or
> when -kb is used and/or a RCS state and/or some other mechani
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> [ On Friday, July 13, 2001 at 14:20:07 (-0500), Cameron,
> Steve wrote: ]
> > Subject: RE: How well does CVS handle other types of data?
> >
> > Re-reading my original message, I see I failed to mention
> t
[ On Friday, July 13, 2001 at 16:40:47 (-0400), Noel L Yap wrote: ]
> Subject: Re: How well does CVS handle other types of data?
>
> I think this is only partially true. Since CVS doesn't currently absolutely
> know whether there are any remaining conflicts, why would it be a r
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Friday, July 13, 2001 at 00:13:15 (-0700), Paul Sander wrote: ]
>> Subject: RE: How well does CVS handle other types of data?
>>
>> Whenever a merge is required, check if the -kb keyword expansion flag
>> is applicabl
>--- Forwarded mail from [EMAIL PROTECTED]
>Just thought I'd mention one problem with trying to store binary
>files in CVS that nobody has mentioned yet
>It's not too hard to get diff to run out of memory with binary
>files, (compared to ascii files.) I have one file in my repository
>that
>If you want to turn automated merging off (either globally or on a
>per-file basis) in CVS then you must first define a mechanism for
>telling CVS when a manual merge has been completed (without any
>remaining conflicts, of course). This is easy for the case of
>concurrent edits, and harder for
[ On Friday, July 13, 2001 at 14:20:07 (-0500), Cameron, Steve wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> Re-reading my original message, I see I failed to mention those binary
> files were 3rd party object code for which we do not have access to
>
>[ On Friday, July 13, 2001 at 13:11:56 (-0400), Noel L Yap wrote: ]
>> Subject: RE: How well does CVS handle other types of data?
>>
>>
>> That's right. You won't have problems with binary files in CVS 'cos they're
not
>> in CVS. This does
[ On Friday, July 13, 2001 at 12:19:09 (-0700), Jimmy Rimmer wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> Or, you could just use the patch for reserved checkouts:
> http://www.cvshome.org/cyclic/cvs/dev-reserve.html
No, you can't. That does nothing
[ On Friday, July 13, 2001 at 11:47:27 (-0700), Mike Castle wrote: ]
> Subject: Re: How well does CVS handle other types of data?
>
> And it is one that cvs supports VERY well. Why should I have to have two
> solutions for the same problem of working remotely? cvs and scp or rsync
Come on guys...for goodness sake, give it a rest (or take it offline).
I think it is safe to say that most of the subscribers of this list would
rather not have all this bickering cluttering their Inbox.
Agree to disagree, and leave it at that.
- Dennis
___
[ On Friday, July 13, 2001 at 14:02:27 (-0400), Noel L Yap wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> >You still have to plan your use carefully, but at least with plain RCS
> >you're less likely to get trapped into trying to automate your me
> > Given all that you've stated below, it seems that the crux
> of your argument
> > turns on the ability of a file to be "mergable". In my
> unadorned, pooh-like
> > brain, I ask the simple (and rhetorical) question, "why?"
> Why can't I have a
> > simple switch which tells CVS that for thi
[ On Friday, July 13, 2001 at 13:58:39 (-0400), Noel L Yap wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> Then I fail to see how, as you implied, Aegis will _prevent_ bug fix branches.
It doesn't prevent them. It didn't really allow them originall
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>
> [ On Friday, July 13, 2001 at 08:39:09 (-0500), Cameron,
> Steve wrote: ]
> > Subject: RE: How well does CVS handle other types of data?
> >
> > On the issue of whether storing binary files in CVS is a go
[ On Friday, July 13, 2001 at 10:19:49 (-0700), Jimmy Rimmer wrote: ]
> Subject: Please, stop. (was RE: How well does CVS handle other types of data?)
>
> CVS is a tool, not a policy. What people love about CVS is that it is a
> tool that fits just about ANY policy they can devise.
Well, no
On Thu, Jul 12, 2001 at 04:26:59PM -0400, Greg A. Woods wrote:
> [ On Thursday, July 12, 2001 at 08:22:54 (-0700), Mike Castle wrote: ]
> > Except that that is a bit of a pain in the ass to support for remote
> > access.
>
> Why? Surely you can think of other ways of copying files across a
> net
[ On Friday, July 13, 2001 at 12:39:29 (-0400), Steven Rosenstein wrote: ]
> Subject: Re: How well does CVS handle other types of data?
>
> Given all that you've stated below, it seems that the crux of your argument
> turns on the ability of a file to be "mergable".
[ On Friday, July 13, 2001 at 13:11:56 (-0400), Noel L Yap wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
>
> That's right. You won't have problems with binary files in CVS 'cos they're not
> in CVS. This doesn't mean you
>[ On Friday, July 13, 2001 at 11:00:40 (-0400), Noel L Yap wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>>
>> >Indeed as the above quoted documentation hints the initial introdcution
>> >of '-kb' to RCS itself was also primarily
>Aegis doesn't guarantee no bugs. It simply requires a new test for
>every change and re-runs all the old tests, as well as the new test, on
>the submitted new code before it can become the baseline.
>
>If the rest of your process is "working" then no bugs will ever be
>re-introduced. If the ch
I'm new to the list and was enjoying myself until this flamewar erupted. I
haven't read ahead to the 50-odd posts that are in my INBOX this morning,
but I just want to make one point, and as clearly as I can.
> I don't think that any of us really want cvs to merge
> non-mergable files,
> just t
[ On Friday, July 13, 2001 at 00:13:15 (-0700), Paul Sander wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> Whenever a merge is required, check if the -kb keyword expansion flag
> is applicable. If it is (via command line, .cvsrc, or RCS file, in that
>
[ On Friday, July 13, 2001 at 09:02:28 (-0600), Gray, Ryan wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> >What is CVS?
> >
>
> > CVS is a version control system. Using it, you can record the
> >
[ On Friday, July 13, 2001 at 11:00:40 (-0400), Noel L Yap wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> >Indeed as the above quoted documentation hints the initial introdcution
> >of '-kb' to RCS itself was also primarily to deal with EOL i
[ On Friday, July 13, 2001 at 10:39:25 (-0400), Noel L Yap wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> I don't see how any system (let alone tools) can ever absolutely guarantee no
> bugs. If it can, then it might as well guarantee no security hole
[ On Friday, July 13, 2001 at 09:25:58 (-0500), Thornley, David wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> Because, so far, nobody's shown me how to make my problems, such as they
> are, easier to manage than if I just use CVS.
Well, that might ju
>That's a moot point Steve. If your build system (makefiles, scripts,
>source to tools, etc.) is also checked in to your CVS tree then it will
>be tagged and you can "cvs checkout; make" and you'll still ``get
>_everything_'' but you won't have *any* problems with binary files in
>CVS!
That's r
[ On Friday, July 13, 2001 at 08:39:09 (-0500), Cameron, Steve wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> On the issue of whether storing binary files in CVS is a good
> idea, vs. trying to use "something else" in conjuction with CVS,
> my
OTECTED] (Greg A. Woods)
To: Lan Barnes <[EMAIL PROTECTED]>
cc: CVS-II Discussion Mailing List <[EMAIL PROTECTED]> (bcc: Steven
Rosenstein/FTCI)
Subject: Re: How well does CVS handle other types of data?
[ On Thursday, July 12, 2001 at 15:59:25 (-0700), Lan Barnes wrote:
>While the ability to use CVS to do merges of branches is but one
>advantage of CVS, the need of CVS to do merges on a regular basis is one
>of the requirements it has on the data it manipulates.
This situation can be avoided (not prevented) with proper procedures.
>Indeed as the above quoted d
>What is CVS?
>
> CVS is a version control system. Using it, you can record the
>history of your source files.
>
>
At the risk of fanning the flames here, I feel I must give my opinion that
"source fil
>> Why, in the name of Babbage, is that supposed to be better? I still
>> can't automatically merge binaries, so it's no advantage there. So
>> what do I get if I do that?
>
>but you can't avoid having to do something equivalent to merging of
>opaque format binary files with CVS!
You can if yo
>CVS is not, by itself, a configuration management system any more than
>it is a build system. It does have several very important features that
>allow it to facilitate CM though...
Yes, but it is a version control system. That's what wer'e talking about here.
Noel
This communication is fo
>[ On Thursday, July 12, 2001 at 20:51:00 (-0400), Noel L Yap wrote: ]
>> Subject: RE: How well does CVS handle other types of data?
>>
>> The key word here is avoid, No system can ever prevent concurrent edits.>
>
>Huh? If there's no branching support, and
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>
> [ On Thursday, July 12, 2001 at 16:53:53 (-0500), Thornley,
> David wrote: ]
> > Subject: RE: How well does CVS handle other types of data?
> >
> > Except that I'm not
Just thought I'd mention one problem with trying to store binary
files in CVS that nobody has mentioned yet
It's not too hard to get diff to run out of memory with binary
files, (compared to ascii files.) I have one file in my repository
that I can't commit to because of this. Luckily, it'
>--- Forwarded mail from Greg Woods
>[ On Thursday, July 12, 2001 at 18:23:51 (-0700), Paul Sander wrote: ]
>> Subject: RE: How well does CVS handle other types of data?
>>
>> I remind you of the definition of source files: Files that cannot be derived
>> automati
>--- Forwarded mail from Greg Woods
>[ On Thursday, July 12, 2001 at 18:16:29 (-0700), Paul Sander wrote: ]
>> Subject: Re: How well does CVS handle other types of data?
>>
>> Every type of file is mergeable; trivially, the merge can be complete
>> replacement.
>--- Forwarded mail from Greg Woods:
>[ On Friday, July 13, 2001 at 11:06:30 (+1000), Sven Dowideit wrote: ]
>> Subject: RE: How well does CVS handle other types of data?
>>
>> Greg - what is wrong with providing extra support for non-mergable files?
>There wouldn&#x
[ On Friday, July 13, 2001 at 17:44:45 (+1200), Chris Cameron wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> According to the original author of CVS, merging was ONE OF SIX advantages
> of CVS, not THE advantage!
You missed the point, again, Chris!
While
> From: Greg A. Woods [mailto:[EMAIL PROTECTED]]
> Sent: Friday, 13 July 2001 4:51 p.m.
> To: Chris Cameron
> Cc: CVS-II Discussion Mailing List
> Subject: RE: How well does CVS handle other types of data?
>
>
> [ On Friday, July 13, 2001 at 13:50:34 (+1200), Chris Cameron
[ On Friday, July 13, 2001 at 13:50:34 (+1200), Chris Cameron wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> We need:
> 1. Ability to recreate a particular contour of file versions
> 2. Ability to work across multiple directories
Good. If tha
How well does CVS handle other types of data?
[ On Thursday, July 12, 2001 at 20:51:00 (-0400), Noel L Yap wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> The key word here is avoid, No system can ever prevent concurrent edits.
Huh? If there's no br
[ On Thursday, July 12, 2001 at 18:23:51 (-0700), Paul Sander wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> I remind you of the definition of source files: Files that cannot be derived
> automatically from anything else. The term "source file"
[ On Thursday, July 12, 2001 at 18:16:29 (-0700), Paul Sander wrote: ]
> Subject: Re: How well does CVS handle other types of data?
>
> Every type of file is mergeable; trivially, the merge can be complete
> replacement. In other words, a viable merge algorithm is a 3-way switc
[ On Friday, July 13, 2001 at 11:15:59 (+1000), Sven Dowideit wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> you are about the only person i have ever met who would argue that
> non-mergable files are not source files it they are used to build somethi
[ On Thursday, July 12, 2001 at 20:51:00 (-0400), Noel L Yap wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> The key word here is avoid, No system can ever prevent concurrent edits.
Huh? If there's no branching support, and no concurrent editing
suppor
[ On Friday, July 13, 2001 at 11:06:30 (+1000), Sven Dowideit wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> Greg - what is wrong with providing extra support for non-mergable files?
There wouldn't be any problem if you could do it without breaking either
and
Life, don't talk to me about life (Marvin - HHGTTG)
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Greg A. Woods
> Sent: Friday, 13 July 2001 12:09 p.m.
> To: Thornley, David
> Cc: [EMAIL PROTECTED]
> Subject: RE: H
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Friday, July 13, 2001 at 10:01:19 (+1200), Chris Cameron wrote: ]
>> Subject: RE: How well does CVS handle other types of data?
>>
>> But Greg, you say CVS is a source code management tool (really an ASCII text
>> f
ct: RE: How well does CVS handle other types of data?
>
>
> [ On Friday, July 13, 2001 at 10:01:19 (+1200), Chris Cameron wrote: ]
> > Subject: RE: How well does CVS handle other types of data?
> >
> > But Greg, you say CVS is a source code management tool (really
> an
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Thursday, July 12, 2001 at 15:59:25 (-0700), Lan Barnes wrote: ]
>> Subject: Re: How well does CVS handle other types of data?
>>
>> You've made your position abundantly clear, and yet I still do not
>> understa
ay, July 13, 2001 10:00 AM
> To: Lan Barnes
> Cc: CVS-II Discussion Mailing List
> Subject: Re: How well does CVS handle other types of data?
>
>
> [ On Thursday, July 12, 2001 at 15:59:25 (-0700), Lan Barnes wrote: ]
> > Subject: Re: How well does CVS handle other types o
>> From: Lan Barnes [mailto:[EMAIL PROTECTED]]
>>
>> I really fail to see the technical reason for deprecating using CVS
>> archives to store -- and tag -- binaries necessary for a build. The
>> disk space involved is a nonissue for us (space is cheap), and the
>> issue of avoiding simultaneous
[ On Friday, July 13, 2001 at 10:01:19 (+1200), Chris Cameron wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> But Greg, you say CVS is a source code management tool (really an ASCII text
> file management tool, given all the caveats you add) and the manual e
[ On Thursday, July 12, 2001 at 16:53:53 (-0500), Thornley, David wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> Except that I'm not banging my head against the wall, and it doesn't
> hurt. I don't know about the rest of you, but I'm no
[ On Thursday, July 12, 2001 at 15:59:25 (-0700), Lan Barnes wrote: ]
> Subject: Re: How well does CVS handle other types of data?
>
> You've made your position abundantly clear, and yet I still do not
> understand your ideas -- nor your vehemence. So what is left is that we
> From: Lan Barnes [mailto:[EMAIL PROTECTED]]
>
> I really fail to see the technical reason for deprecating using CVS
> archives to store -- and tag -- binaries necessary for a build. The
> disk space involved is a nonissue for us (space is cheap), and the
> issue of avoiding simultaneous edits e
"Greg A. Woods" wrote:
>
> > From: Lan Barnes [mailto:[EMAIL PROTECTED]]
> >
> > I really fail to see the technical reason for deprecating using CVS
> > archives to store -- and tag -- binaries necessary for a build. The
> > disk space involved is a nonissue for us (space is cheap), and the
> > i
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, July 12, 2001 3:24 PM
> [ On Thursday, July 12, 2001 at 09:38:17 (-0500), Thornley,
> David wrote: ]
> > Subject: RE: How well does CVS handle other types of data?
> &
e (Marvin - HHGTTG)
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Greg A. Woods
> Sent: Friday, 13 July 2001 8:38 a.m.
> To: Peter Fox
> Cc: CVS-II Discussion Mailing List
> Subject: RE: How well does CVS handle other types o
[ On Thursday, July 12, 2001 at 09:31:09 (-0700), Peter Wolfe wrote: ]
> Subject: Re: How well does CVS handle other types of data?
>
> be used AND be adopted by new users. I would hold out Perl as an
> example of a tool (in this case a language) with the philosophy of
> "T
[ On Thursday, July 12, 2001 at 11:38:21 (-0400), Peter Fox wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> Sorry my "graphic people" are the same people who are writing Delphi code.
So, have someone put on a virtual "graphics people"
[ On Thursday, July 12, 2001 at 09:38:17 (-0500), Thornley, David wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> > Learn to separate your unmergable files form your other stuff
> > and build
> > procedures and processes to bring them tog
[ On Thursday, July 12, 2001 at 08:22:54 (-0700), Mike Castle wrote: ]
> Subject: Re: How well does CVS handle other types of data?
>
> On Thu, Jul 12, 2001 at 01:10:55AM -0400, Greg A. Woods wrote:
> > there your build process can easily be constructes to always pull the
> >
[ On Thursday, July 12, 2001 at 11:16:17 (-0400), Peter Fox wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> Sorry, but to name binary icon files to identify the releases that they
> should be present in. This seems a truly weird solution. Surely I shouldn
> -Original Message-
> From: Lan Barnes [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, July 12, 2001 2:55 PM
> To: CVS-II Discussion Mailing List
> Subject: Re: How well does CVS handle other types of data?
> I really fail to see the technical reason for deprecating using
"Greg A. Woods" wrote:
>
> [ On Wednesday, July 11, 2001 at 11:18:01 (-0700), Lan Barnes wrote: ]
> > Subject: Re: How well does CVS handle other types of data?
> >
> > Hmm. If I exclude the binaries in my projects from CVS, how can I apply
> > tags to the
On Wed, Jul 11, 2001 at 03:42:20PM -0400, Jeff King wrote:
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> > Mike Castle
> > Sent: Wednesday, July 11, 2001 2:56 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re:
Hi All,
I am one of the list lurkers that rarely says anything but does follow
the threads of discussion. I believe that Peter Fox (and Paul Sander
before him) has hit the core of the issue. We at our shop use CVS to
manage source code (and my definition is that of Paul Sander ...
anything that
>
> How would I know? I'm not a graphics artist! I can imagine
> the process
> though and it doesn't seem that complex or difficult -- it's simply a
> matter of understanding the intent of the two changes and knowing
> whether they're in conflict or not and if they are then using
> the intent
L PROTECTED]]
> Sent: Thursday, July 12, 2001 1:11 AM
> To: Lan Barnes
> Cc: CVS-II Discussion Mailing List
> Subject: Re: How well does CVS handle other types of data?
>
>
> [ On Wednesday, July 11, 2001 at 11:18:01 (-0700), Lan Barnes wrote: ]
> > Subject: Re: How we
On Thu, Jul 12, 2001 at 01:10:55AM -0400, Greg A. Woods wrote:
> there your build process can easily be constructes to always pull the
> appropriate revision of a binary file into any given release build.
Except that that is a bit of a pain in the ass to support for remote
access.
Whereas, if on
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>
> [ On Wednesday, July 11, 2001 at 11:35:14 (-0500), Thornley,
> David wrote: ]
> > Subject: RE: How well does CVS handle other types of data?
> >
> > OK, what? For my purpo
This is one reason I use the terminology "non-mergable" instead of "binary". In
no way are the two related.
Noel
Hi everybody,
As I saw a lot comments on this thread, perhaps her is it a nice solution ...
So here just a suggestion (if you have big disk space and powerful server), it's
to conv
>Concurrent editing in the sense that phrase is most commonly used with
>CVS is not the only, or even the major, problem here! This issue can
>much more easily be avoided by external task management.
>
>Merging of branches (which is a totally different form of concurrent
>editing that's not nece
Hi everybody,
As I saw a lot comments on this thread, perhaps her is it a nice solution ...
So here just a suggestion (if you have big disk space and powerful server), it's
to convert your binary file to HEX (like UUENCODE do for email), and make a
commit as ASCI file ! And doing the inverse ope
[ On Wednesday, July 11, 2001 at 11:35:14 (-0500), Thornley, David wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> OK, what? For my purposes, it has to support concurrent development
> and branching, and right now my company isn't going to spend gobs
&g
[ On Wednesday, July 11, 2001 at 13:28:55 (-0400), Peter Fox wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> But why re-invent the wheel. If CVS gives you 95% of what you want, when
> spend 10 weeks on obtaining the last 5%. It's not worth it.
IFF...
[ On Wednesday, July 11, 2001 at 14:13:29 (-0700), Mike Castle wrote: ]
> Subject: Re: How well does CVS handle other types of data?
>
> Can you suggest such a tool? That's free? That supports networking? That
> supports branching?
>
> Exactly what IS the better mo
[ On Wednesday, July 11, 2001 at 16:31:42 (-0400), Jeff King wrote: ]
> Subject: RE: How well does CVS handle other types of data?
>
> The difference is that CVS is an excellent tool for managing source code,
> because the VAST majority of cases involving concurrent editing of sour
1 - 100 of 129 matches
Mail list logo
