A chroot environment is only good at containing what's inside it. It
does not prevent access to the chroot environment from outside.
In other words, chroot is fine for containing servers so that they cannot
access the rest of the system. But chroot does not protect something
from shell users, un
>--- Forwarded mail from [EMAIL PROTECTED]
>> > CVS's support for bug
>> > tracking is poor to nonexistent and many people have commented on
>> > it and requested better support.
>>
>> That's because CVS is not a bug tracking tool. It's an archive
>> system. Only an archive system. If you wan
You will seriously miss directory versioning and the ability to reorganize
your source code at will. Depending on your process, you might also miss
the ability to store named attributes on your artifacts. My users also
make heavy use of the graphical version tree browser, which displays
merges.
There is an aspect of ClearCase that makes its merge operations significantly
superior to CVS, which is in the way it identifies the common ancestor of
of a 3-way merge. It considers the results of past merges, not just the
intersection of the branches. The effect is that resolved conflicts
don't
>--- Forwarded mail from [EMAIL PROTECTED]
>> Thanks. Looks like merges must be difficult in CVS. A lot of manual
>work.
>Oh, do you know of a configuration management system that can read human
>minds?=20
>Basically, two changes have been made to the *same spot*: one in your
>work area, and o
Take a look at the rinfo and lmerge programs at
http://www.wakawaka.com/source.html
They're not a complete solution to your problem, but they get you a lot
closer to it.
--- Forwarded mail from [EMAIL PROTECTED]
Has anyone been tasked to make release notes out of the history log
file?
I was wond
Can CVSup so something useful if a person at both sites commits to the
trunk between updates? How is that type of conflict resolved?
What if people at both sites apply the same tag?
--- Forwarded mail from [EMAIL PROTECTED]
Couldn't you use something like CVSup and automatically trigger its
exe
>--- Forwarded mail from [EMAIL PROTECTED]
>> I would like to know that whether CVS supports multisite or not. Multisite
>> in the sense a true multisite solution
>> not just mirroring the disk on, which the CVS repository exists to another
>> machine, and periodically syncing it.
>No, it doesn't
Have you considered one or more of the following?
- Configure your web server to disallow serving the CVS meta-data.
- Check out to a staging area, then perform a quick rename shuffle
to replace the deployed web site very quickly.
--- Forwarded mail from [EMAIL PROTECTED]
I would like to know
What you call a "common linkage sandbox" is what is usually called a
"baseline" in SCM circles. There are lots of ways to manage them.
They can be built automatically on a fixed schedule, or they can be
built on demand. They can be populated with "cvs update -d" or with
something more sophistica
The consensus of the maintainers has historically been to never add features
that they don't personally need, unless somneone supplies code, documentation,
and a regression suite. And then it gets integrated at their discretion.
There are already at least two major splinter groups using features
What happens when you run "rsh remoteHost echo hello world", where
"remoteHost" is the name of the machine storing your repository?
Chances are that your .rhosts file isn't configured properly for
the client and server machines. Also make sure its mode is 600.
--- Forwarded mail from [EMAIL PROT
There's a lot to be said for denying all users the ability to log in to a
critical application server (i.e. not giving them accounts), and then
connecting the applications up to sockets and letting them do their own
user authentication and access authorization. This is particularly true
if you nee
>--- Forwarded mail from [EMAIL PROTECTED]
>There is allways a mixture of architectures! Even if it is a
>linux-only setup, you can be sure that there are (or at least that
>there will eventually be) different distributions!
That's like saying that Solaris 2.4 and Solaris 2.9 are different
archit
>--- Forwarded mail from [EMAIL PROTECTED]
>On Fri, Oct 25, 2002 at 01:49:26PM -0700, Paul Sander wrote:
>> Shouldn't be too hard to write a script that converts the output of
>> "tar -tf" into an RPM spec.
>Still doesn't help me to keep multiple versio
>--- Forwarded mail from [EMAIL PROTECTED]
>On Fri, Oct 25, 2002 at 09:58:15AM -0700, Paul Sander wrote:
>> Each platform usually has a packaging method available as well. Solaris,
>> IRIX, HP-UX, AIX, Linux, and *BSD Unix all have packaging systems supplied
>> with th
Each platform usually has a packaging method available as well. Solaris,
IRIX, HP-UX, AIX, Linux, and *BSD Unix all have packaging systems supplied
with them. Microsoft's systems have commercial products, e.g. InstallShield
and InstallAnywhere that perform these tasks.
Typically, the administrat
>--- Forwarded mail from [EMAIL PROTECTED]
>My question was "Why is cvs trying to read from Attic
>when I do cvs add"
The reason it reads the attic is to look for files that were either
removed by a prior "cvs remove", or added on a branch. In both cases,
the RCS file already exists, and under
>--- Forwarded mail from [EMAIL PROTECTED]
>Paul Sander writes:
>>
>> But the following streams of commands are exactly equivalent (assuming
>> rtag were modified to accept both -D and -r options):
>>
>> cvs checkout -r branch module cvs rtag -D n
>--- Forwarded mail from [EMAIL PROTECTED]
>Paul Sander wrote:
>> I claim that "y" == "now" is a common special case. Therein lies the
>> "tag the head of a branch" issue.
> It is an *uncommon* special case. In every other case
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Wednesday, October 9, 2002 at 10:13:42 (-0700), Paul Sander wrote: ]
>> Subject: Re: Tag locking change
>>
>> There are lots of cases where someone demands "tag branch x as of time y".
>What the heck does tha
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Tuesday, October 8, 2002 at 22:32:18 (-0700), Mike Ayers wrote: ]
>> Subject: Re: Tag locking change
>>
>> Greg A. Woods wrote:
>>
>> > If you really Really REALLY want to tag the head of a branch then just
>> > check out the branch (or do a "cvs
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Tuesday, October 8, 2002 at 16:11:42 (-0700), Paul Sander wrote: ]
>> Subject: Re: Tag locking change
>>
>> >--- Forwarded mail from [EMAIL PROTECTED]
>>
>> >Mark writes:
>> >>
>> &
>--- Forwarded mail from [EMAIL PROTECTED]
>Mark writes:
>>
>> If one wants to tag the latest on a branch, why should one have to create a
>> workarea to do it?
>How do you know you want to tag the latest on a branch? Either you have
>no idea what the "latest" actually is, or you know that no
that something currently being checked in will not be in the tagging
process initiated with a rtag.
( I am assuming I wait for 10 minutes after a proper file as needed by me
was checked in ).
>From: [EMAIL PROTECTED] (Larry Jones)
>Paul Sander writes:
>>
>> Another serious issue
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Monday, October 7, 2002 at 12:39:29 (-0400), Larry Jones wrote: ]
>> Subject: Re: Tag locking change
>>
>> Paul Sander writes:
>> >
>> > Another serious issue is when someone commits while an rtag
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Sunday, October 6, 2002 at 18:01:01 (-0400), Larry Jones wrote: ]
>> Subject: Tag locking change
>>
>> I've checked in a change to the [r]tag command to go back to locking
>> one directory at a time (correctly, this time) rather than locking the
>>
>--- Forwarded mail from [EMAIL PROTECTED]
>Daniel Gibbs writes:
>> I was wondering if it was possible to disable conflict checking.
>No, of course not. A conflict means that CVS has no idea how to merge
>two independent changes -- how do you "disable" not knowing how to do
>something?!?
One
You can't do it with CVS alone. The output of "cvs log" can be parsed and
reformatted into a better report, but doing so is not foolproof due to the
way the rlog formats its output. (User comments can look like the syntax
RCS uses to identify versions.)
Take a look at the rinfo and lmerge progr
>--- Forwarded mail from [EMAIL PROTECTED]
>I'm forwarding an email from a coworker who is our configuration manager
>and has a Clearcase background. We however, use CVS in our office and
>are attempting to implement some Clearcase techniques (features) in
>CVS. If you can provide any assistanc
>--- Forwarded mail from [EMAIL PROTECTED]
>> 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 offer
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Thursday, September 12, 2002 at 10:41:29 (-0700), Paul Sander wrote: ]
>> Subject: Re: moving a file
>>
>> Using this method, technically, no history is lost. However, it is
>> fragmented. You cannot use a singl
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Thursday, September 12, 2002 at 16:26:28 (+0200), Massimiliano Cialdi wrote: ]
>> Subject: moving a file
>>
>> how can I move a file from a directory to another whithout loose the history?
> $ cd ..
> $ cp foodir/barfile blahdir
>
For each file under source control, you can do a "cleartool lsvtree"
and check out every version in the version tree and check it in using
RCS to produce a proper RCS file. Then copy the RCS file into your CVS
repository.
However, there's something lost in the translation: Because there's no
CV
This can
be done either on the command line directly when adding files, or by
writing a light wrapper about "cvs add" and supplying a table.
>-Original Message-
>From: Paul Sander [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, 29 August 2002 10:16
>To: [EMAIL PROTECTED]; [
This only works if the shared files are in separate directories from the
rest of the source. If a file is shared across multiple projects and it
must appear in the same directory as project-specific sources, then it
can't be done with CVS alone; your build system will have to do something
funky t
>--- 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
>--- Forwarded mail from [EMAIL PROTECTED]
>Frederic Brehm wrote:
>> The CVS clients already do this. The problem comes when people use a
>> file system cross mounted on several different kinds of OS, checkout on
>> one OS, and then edit and commit on another OS.
>I wonder why people do this?
>--- Forwarded mail from [EMAIL PROTECTED]
>On Mon, 26 Aug 2002, Paul Sander wrote:
>> >> Date: Mon, 26 Aug 2002 14:12:04 -0700 (PDT)
>> >> From: Pat Young <[EMAIL PROTECTED]>
>> >> To: [EMAIL PROTECTED]
>> >> Subject: [info-cvs]
>--- Forwarded mail from [EMAIL PROTECTED]
>On Mon, 26 Aug 2002, Pat Young wrote:
>> Date: Mon, 26 Aug 2002 14:12:04 -0700 (PDT)
>> From: Pat Young <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED]
>> Subject: [info-cvs] Locking a branch
>>
>> What is the best way to lock a branch? Should I use
>H
It looks like this is another reason to make the distinction between
sticky branch and version tags. With branch tags, I agree with Kaz.
With version tags, I agree with Noel.
--- Forwarded mail from [EMAIL PROTECTED]
On Mon, 26 Aug 2002, Noel Yap wrote:
> I'm not sure if this is a known proble
I can think of a few ways to do it.
1. Use your packaging/deployment system to distribute many copies of the
file but install the proper one according to the selected configuration.
2. Keep a collection of these files under source control, and use build
targets to rename them as needed
tates and tags.
--- Forwarded mail from [EMAIL PROTECTED]
On Fri, Aug 09, 2002 at 12:50:06PM -0700, Paul Sander wrote:
> Each site owns its own trunk. Each site creates a branch that is used for
> importing from the other site(s); these branches map to the trunk(s) at the
> remote site
>--- Forwarded mail from [EMAIL PROTECTED]
>On Fri, Aug 09, 2002 at 12:50:06PM -0700, Paul Sander wrote:
>> Each site owns its own trunk. Each site creates a branch that is used for
>> importing from the other site(s); these branches map to the trunk(s) at the
>> r
There has been a fair amount of discussion about this topic in the past,
and I believe that someone has a working implementation that follows this
model:
Each site owns its own trunk. Each site creates a branch that is used for
importing from the other site(s); these branches map to the trunk(s)
>--- Forwarded mail from [EMAIL PROTECTED]
>On Thu, Aug 08, 2002 at 12:31:17PM -0700, Schwenk, Jeanie wrote:
>> How can a vendor tag and vendor branch be verified as being present?
>This:
>> branch: 1.1.1
>is a red herring. It names the "default branch"; it's *not* used
>to determine whether a
There's no sure-fire 100% absolute method to discover if there's a vendor
branch. But there are two heuristics that are close enough for practical
purposes.
First, if the RCS file's "branch:" attribute is set then its value is name
of the vendor branch. But that attribute is cleared during the
You might consider a simpler change management system that doesn't
involve the second repository. If you search through the info-cvs
archives for submit/assemble or release/integrate, you'll find a
very detailed description of a method that tracks manifests and
changelists. It's much lighter wei
--- Forwarded mail from [EMAIL PROTECTED]
> I've been using CVS for quite some time but still not very
>much confident using it. I've been working on both Solaris/Linux
>and Windows platform. Please let me know :-
>1) where I can find good resources on Configuration Management
>in general, and
This topic was discussed at length in the past. The consensus seems to
be that using a commitinfo script is the proper way to enforce naming
conventions. The proposal to add a new trigger that fires at the time
of a "cvs add" (perhaps an "addinfo" file) to provide an earlier
opportunity to enfor
Last September I posted a patch that allows for the integration of new
merge tools based on file extension. It's alpha-quality code, but a
good demonstration that, despite what certain individuals have claimed,
the CVS design is robust enough to accommodate an extensible merge
mechanism. I b
You're using a Windows client to access your CVS repository, right?
You can correct the situation by having your CVS admin rename the RCS
files inside the repository, then do a "cvs update" in your workspace.
Then install the necessary scripts in your *info files to enforce
naming conventions upo
>--- Forwarded mail from [EMAIL PROTECTED]
>Greg is talking about the second issue. I have an
>inkling keeping this info on a per-version basis won't
>work but I haven't come up with anything substantial.
Here's one:
- Create a new file and check in a few versions on the trunk.
- Create a bran
>--- Forwarded mail from [EMAIL PROTECTED]
>> > > No. Not on extension, but based on *regular
>> expressions*, or at least
>> > > shell-style pattern matching expressions.
>> Extensions are too
>> > > simplistic. (c.f. CVSROOT/cvswrappers, CVSROOT/cvsignore)
>> >
>> > Extensions would
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Friday, May 3, 2002 at 14:49:11 (-0500), Sean Hager wrote: ]
>> Subject: RE: merge mode for XML
>>
>>
>>
>> > No. Not on extension, but based on *regular expressions*, or at least
>> > shell-style pattern matching expressions. Extensions
>--- Forwarded mail from [EMAIL PROTECTED]
>> Yeah. That'd be a cool feature. But then, CVS will no longer be a
>> standalone program. If you move the repository to another server
>> where the modules are missing, how would you expect CVS to behave?
>The plugins would be part of the m
On Tuesday, April 30, 2002, at 03:33 PM, [EMAIL PROTECTED] wrote:
> I have one config file that must exist in several directories in my
> project.
> I would like to be able to have CVS create this file in all its
> locations
> and still only have it stored once in the repository. Any idea ho
On Wednesday, May 1, 2002, at 02:36 PM, [EMAIL PROTECTED] wrote:
>
> We have all our source code in the CVS repository as
> one project. Now we want to start a new project in
> CVS. But we will be requiring files from the existing
> project into the new project. How can we copy/move the
> files
gt; subprogram architecture into CVS. Then we could implement an XML
> wrapper.
>
> sean.
>
>
>> -Original Message-
>> From: Paul Sander [mailto:[EMAIL PROTECTED]]
>> Sent: Monday, April 29, 2002 12:43 PM
>> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
&
Once again, take a look at message ID# [EMAIL PROTECTED]
posted to this forum on September 16, 2001. It illustrates one way (though
perhaps not the best way) to do just this. It relies on a lookup table that
looks up a diff tool given a file's name.
A better implementation would be to code a sy
On Friday, April 26, 2002, at 06:57 AM, [EMAIL PROTECTED] wrote:
>
> Should CVS be used to stored the executable that is generated at the end
> of a build process under a special directory, say release/ ?
Not in-place. Doing so would interfere with the normal development
process because you'
First, see if doing a "cvs admin -kkv" on the file produces meaningful
results for you. If it doesn't, you'll have to re-add the file under a
different name. (CVS' remove and add functions recycle the existing
revision history, with all of its RCS attributes preserved.)
If neither of these opti
Good idea, but I'm sure that there's one legitimate user somewhere in
Korea who doesn't want to lose access to this list.
--- Forwarded mail from [EMAIL PROTECTED]
how about filtering anything comping from *.co.kr !
>If you are good in defining maildrop-filterrules you can mail me
>a filterdesc
A different method that I've been using successfully for years is a
mechanism called "buildrefs". It's a primitive publish/subscribe
tool that allows a build to advertise various resources in the form
of paths, and another build to query for such resources.
Some of my projects use this to comput
>--- Forwarded mail from [EMAIL PROTECTED]
>--- Paul Sander <[EMAIL PROTECTED]> wrote:
>> Hmmm... I have two problems with this. First,
>> renaming a file
>> should not break the ability to check out prior
>> releases by tag
>> or branch/datestam
I find that it's best to keep the version tree as shallow as possible,
with regard to branches. It makes it easier to wrap one's brain around
all of the different variants of the project.
The best way I've found to do that is to plan on making the most distant
future release from the trunk, and
>--- Forwarded mail from [EMAIL PROTECTED]
>--- Paul Sander <[EMAIL PROTECTED]> wrote:
>> Keep in mind that "permissions" include not only the
>> file's mode,
>> but also its user and group ownerships, plus
>> whatever additional
>> mech
>--- Forwarded mail from [EMAIL PROTECTED]
>--- Paul Sander <[EMAIL PROTECTED]> wrote:
>> >> Permissions on a directory basis are tough if
>> files
>> >> are linked to
>> >> multiple directories that have different
>> >> perm
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Tuesday, March 5, 2002 at 16:12:24 (-0800), Paul Sander wrote: ]
>> Subject: Re: CVS and Jar files: Should you import Jar into the Repository? Why or
>why not
>>
>> RCS stores binary files just fine, though perhaps no
>--- Forwarded mail from [EMAIL PROTECTED]
>We do quite lot of Java developpement with CVS and we handle jars like this :
>1) Jars that _we generate_ are not stored in CVS, only the sources are.
>2) 3rd party Jars that we use are stored on an internal web server (one
>directory per jar with a
>--- Forwarded mail from [EMAIL PROTECTED]
>CVS is meant to be a concurrent versioning system, but
>the design prevents it from achieving this goal when
>it comes to non-diff3-able files. I see no reason why
>this design cannot be changed in order to achieve its
>intended purpose.
The *design*
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Tuesday, March 5, 2002 at 22:01:01 (GMT), Richard Caley wrote: ]
>> Subject: Re: CVS and Jar files: Should you import Jar into the Repository? Why or
>why not
>>
>> If your only reason for using CVS is to get diffs, then you will think
>> differe
>--- Forwarded mail from [EMAIL PROTECTED]
>--- Paul Sander <[EMAIL PROTECTED]> wrote:
>> >--- Forwarded mail from [EMAIL PROTECTED]
>> >Each file and directory are mapped to a ,v archive
>> >file. The contents of the directory archive files
>> are
&
>--- Forwarded mail from [EMAIL PROTECTED]
>--- Paul Sander <[EMAIL PROTECTED]> wrote:
>> Unfortunately, modules can overlap, which means that
>> the new
>> locking mechanism must have a granularity smaller
>> than the
>> module.
>>
>&g
What you're trying to do has been discussed ad-nauseum in this forum for
years. The method you prefer to use, though not popular, has been used
successfully in the past with success.
The "cvs tag -d" command does work in combination with wildcards on the
command line, and it also works with -l a
In that case, commit your first merge to a new branch and repeat the process
until you get in.
>--- Forwarded mail from [EMAIL PROTECTED]
>On Thu, Feb 28, 2002 at 02:22:13PM -0800, Paul Sander wrote:
>> In other words, others have committed to your target branch before you
>>
after
>merge" tags (that do not include "during merge" commits?
>On Thu, Feb 28, 2002 at 01:22:04PM -0800, Paul Sander wrote:
>> What is the reason for locking the repository? Normally, it's to avoid
>> race conditions, e.g. when a commit is done on one of
What is the reason for locking the repository? Normally, it's to avoid
race conditions, e.g. when a commit is done on one of the branches involved
in the merge.
You can avoid locking if you know the version numbers of the contributors
beforehand, or can otherwise identify them uniquely (e.g. wit
Tracking branch points makes it easier to fold changes from branches back
into ancestor branches. By identifying a common ancestor (the branch point)
in addition to a contributor (e.g. a maintenance branch) and a target (e.g.
the HEAD), a 3-way merge is done by "cvs update -jbranchPoint -jbranch"
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Tuesday, February 26, 2002 at 23:51:29 (-0800), Paul Sander wrote: ]
>> Subject: Re: CVS Update Behaviour
>> Yes, some of the tools I listed are nearly worthless (or at
>> least have better alternatives). And in my w
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Tuesday, February 26, 2002 at 16:19:11 (-0800), Paul Sander wrote: ]
>> Subject: Re: CVS Update Behaviour
>>
>> >--- Forwarded mail from [EMAIL PROTECTED]
>>
>> >[ On Tuesday, February 26, 2
so at one time it actually used RCS. It could just as well have
used SCCS or something else entirely just as well.)
Hey wait a minute! In another closely related thread:
>From: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]
>Subject: Re: CVS Update Behaviour
>Mess
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Tuesday, February 26, 2002 at 19:50:23 (-0800), Noel Yap wrote: ]
>> Subject: RE: renames under CVS
>> > We would also need a graph showing how many of those
>> > files could be
>> > harmlessly renamed in the repository (i.e. which
>> > have tags
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Tuesday, February 26, 2002 at 19:05:04 (-0800), Noel Yap wrote: ]
>> Subject: Re: CVS Update Behaviour
>>
>> --- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
>> > You really do know how to get off track and squirm
>> > out from under the
>> > pressur
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Tuesday, February 26, 2002 at 10:27:23 (-0800), Paul Sander wrote: ]
>> Subject: Re: CVS Update Behaviour
>>
>> inclusion, the relationship between the two files becomes variable.
>> In the event that a file is moved
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Tuesday, February 26, 2002 at 01:29:49 (-0800), Paul Sander wrote: ]
>> Subject: Re: CVS Update Behaviour
>>
>> >BTW, 'patch' is a _standard_ Unix tool. It's documented in The Single
>> >UNIX
>--- Forwarded mail from [EMAIL PROTECTED]
>Hello. I have noticed several different kind of lockfiles that CVS
>seems to create (and sometimes leave laying around) and was hoping
>someone could help me out on what they are used for, when are they
>created, where they are created, and when are
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Sunday, February 24, 2002 at 22:09:31 (-0800), Paul Sander wrote: ]
>> Subject: Re: CVS Update Behaviour
>>
>> Hmmm... Let's recap:
>>
>> >> cp $1 $2
>> >> cvs rm -f $1
>>
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Monday, February 25, 2002 at 10:46:14 (-0800), Paul Sander wrote: ]
>> Subject: Re: CVS Update Behaviour
>>
>> >--- Forwarded mail from [EMAIL PROTECTED]
>> >
>> >Free software development d
>--- Forwarded mail from [EMAIL PROTECTED]
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>>
>> [ On Monday, February 25, 2002 at 00:17:58 (-0800), Paul
>> Sander wrote: ]
>> > Subject: Re: CVS Update Behaviour
&
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Sunday, February 24, 2002 at 20:46:05 (-0800), Noel Yap wrote: ]
>> Subject: Re: renaming under CVS
>>
>> I'm starting to think about a scheme where CVS would
>> go through a filename mapping if the usual archive
>> file isn't found (I think this i
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Sunday, February 24, 2002 at 20:59:30 (-0800), Noel Yap wrote: ]
>> Subject: Re: renaming under CVS
>>
>> Let me explain so even you can understand: Developer
>> A should be able to modify a file while developer B
>> renames it. The merge should
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Sunday, February 24, 2002 at 20:13:51 (-0800), Noel Yap wrote: ]
>> Subject: Re: CVS Update Behaviour
>>
>> --- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
>> > "patch" has been a "standard" tool in unix development for nearly two
>> > decades now.
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Monday, February 25, 2002 at 00:17:58 (-0800), Paul Sander wrote: ]
>> Subject: Re: CVS Update Behaviour
>>
>> Renames are not usually a requirement of maintenance, but they are a
>> requirement of new developme
>--- Forwarded mail from [EMAIL PROTECTED]
>--- Paul Sander <[EMAIL PROTECTED]> wrote:
>> >--- Forwarded mail from [EMAIL PROTECTED]
>> >I'm starting to think about a scheme where CVS
>> would
>> >go through a filename mapping if the usual arch
For what it's worth, I'm not convinced that embedding the version numbers
of descendants is really necessary in each of the revisions representing a
directory's contents. I believe that a new revision of each directory is
really needed only when add and removes (and renames) are committed, and
th
>--- Forwarded mail from [EMAIL PROTECTED]
>In article <[EMAIL PROTECTED]>, Paul Sander wrote:
>>>"patch" has been a "standard" tool in unix development for nearly two
>>>decades now. Prior to that the commonly used tool that can do the exa
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Friday, February 22, 2002 at 20:57:01 (-0800), Paul Sander wrote: ]
>> Subject: Re: CVS Update Behaviour
>>
>> >--- Forwarded mail from [EMAIL PROTECTED]
>>
>> >[ On Friday, February 22, 2
een removed to the Attic in the
current release.
>[ On Friday, February 22, 2002 at 20:51:55 (-0800), Paul Sander wrote: ]
>> Subject: Re: CVS Update Behaviour
>> In this latter case, you need to
>> know where in the repository the RCS file sits, and that info isn't
>
>--- Forwarded mail from [EMAIL PROTECTED]
>--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
>> CVS simply cannot ever support the kind of renames
>> some very few of you
>> continually whinning complainers seem to wish to
>> have without
>> introducing fundamentally backwards incompatible
>> chan
201 - 300 of 571 matches
Mail list logo
