--- Forwarded mail from [EMAIL PROTECTED]
At 4:02 PM -0400 6/17/04, Greg A. Woods wrote:
I have no problem using/learning new tools. I'd personally love to be
able to use VooDoo for version control, but there are two problems:
1. It's not free
2. There is no standalone client for it
3. There
--- Forwarded mail from [EMAIL PROTECTED]
At 1:40 PM -0700 6/17/04, Paul Sander wrote:
Why would it not work well to use a CVS Wrapper to binhex (uuencode,
etc.) a binary file and then essentially have CVS to only see your
file as a text file?
The key is that there's a distinction between text
Whew, the smoke's getting thick in here!
From: [EMAIL PROTECTED]
[ On Thursday, June 17, 2004 at 13:06:44 (-0700), Paul Sander wrote: ]
Subject: Re: CVS corrupts binary files ...
Current releases of CVS do the latter. (Don't believe me? Look at
the function named RCS_merge in the rcscmds.c
Are you kidding? One of the bases for the software boom of the '90s
was to fix all that non-compliant COBOL code. Do you think all those
old-timers came out of retirement to do porting?
--- Forwarded mail from [EMAIL PROTECTED]
I thought COBOL died with Y2K, how much COBOL development still
Agreed. Make the user make the change you want committed. Supply a script
to do it if necessary. Then use the *info capability to verify that it
was done.
--- Forwarded mail from [EMAIL PROTECTED]
Anders Carlberg [EMAIL PROTECTED] writes:
Is it possible to modify the files before they are
--- Forwarded mail from [EMAIL PROTECTED]
Jeeva Sarma wrote:
In our team, one developer wants to make tags for a few
files; suppose he is working on 2 bugs, each requiring
changes in 2 or 3 different set of files, he wants to tag
each of those 2 or 3 files with the bug number, so that he
Indeed. You can even have a *info script update the defect database with
the files and version numbers.
Your database maps files to defect numbers? Which product do you use, if
it's not proprietary?
--- Forwarded mail from [EMAIL PROTECTED]
The way we approach this in our team is to have a
So there's no relational query (or equivalent) to perform this function?
Bummer. Not many defect tracking systems seem to offer such a capability
without heavy customization, which is unfortunate.
--- Forwarded mail from [EMAIL PROTECTED]
Well, it's not explicitly supported, but we use the
--- Forwarded mail from [EMAIL PROTECTED]
Source files are any files that cannot
be reproduced automatically.
Nope, that's wrong too.
Source files are those files written and edited by humans.
That's exactly what I said. Read that sentence again.
Source _code_ is human (and machine)
Oops, I omitted the Sept. 16 patch. Here it is at the bottom.
--- Forwarded mail from [EMAIL PROTECTED]
--- Forwarded mail from [EMAIL PROTECTED]
[ On Saturday, June 5, 2004 at 20:52:06 (-0700), Paul Sander wrote: ]
Subject: Re: CVS corrupts binary files ...
Yeah, well, sending such hapless
--- Forwarded mail from [EMAIL PROTECTED]
[ On Saturday, June 5, 2004 at 20:52:06 (-0700), Paul Sander wrote: ]
Subject: Re: CVS corrupts binary files ...
Yeah, well, sending such hapless people away is easier
than fixing the tool.
The tool is not broken -- I.e. there's nothing to fix!
CVS
--- Forwarded mail from [EMAIL PROTECTED]
Greg writes:
CVS is designed _only_ for tracking changes in
human written text files.
Paul writes:
Keep in mind also that there's a difference
between binary files and mergeable files.
The two concepts are in fact orthogonal; there
are mergeable
--- Forwarded mail from [EMAIL PROTECTED]
* On Sat, Jun 05, 2004 at 08:38:15PM -0700 Gianni Mariani wrote:
*
Peter Connolly wrote:
Too dificult to set up, I think Shouldn't cvs have a list of binary
file types preinstalled in the cvswrappers ?
I agree, it should.
I second that ! I did
--- Forwarded mail from [EMAIL PROTECTED]
Adrian Constantin writes:
Or maybe projects for Unix/Linux platforms do not
usualy have binary files, but I don't really think so...
CVS is a *source* control system; source files are rarely binary.
I disagree with this statement. Source files are
--- Forwarded mail from [EMAIL PROTECTED]
Is it a proven thing that CVS can corrupt a binary file if no merges
are tried and no CR/LF boundary rules are broken? In other words, if
I set -kb on a binary file and then do nothing to it but commit
updates and sometimes request an old revision,
--- Forwarded mail from [EMAIL PROTECTED]
Doug Lee [EMAIL PROTECTED] writes:
In other words, if I set -kb on a binary file and then do
nothing to it but commit updates and sometimes request an
old revision, keeping my sandbox in the OS in which it was
checked out, could I ever get a bad
--- Forwarded mail from [EMAIL PROTECTED]
Doug Lee [EMAIL PROTECTED] writes:
I think there are some binary diff algorithms...
Indeed. Consider svn which uses xdelta internally.
To be fair, CvsNt also has ways of dealing better
with binary formats than the cvshome version.
There is
If you're seriously considering option 2, you should take a look at
Monotone. You can find it through freshmeat.net.
--- Forwarded mail from [EMAIL PROTECTED]
Having two geographically distributed development center is one of our
requirements. And guess what! The two teams will be working on
--- Forwarded mail from [EMAIL PROTECTED]
I don't think it's either, I think you're suffering from a fundamental
misconception=20
of some sort about how branches work, but I'm not sure exactly what it
is.
Your explanation (and Larry's now) makes sense, but I wish CVS didn't do
this...
My
ClearCase is capable of supporting a number of branching models. If you
read the ClearCase documentation, it never mentions a branch tree deeper
than 2 levels (including /main), so it's unclear what they really recommend
without taking an advanced class or hiring consultants. And even then you
Your method is a fine one. The thing is, if the parent branch is
empty, then you don't need to create it. You just need to track
its sprout point from its parent so that its children sprout from
the same version. This is mathematically equivalent to creating
a placeholder that is identical to
This is a good application of a release integration process. Periodically
pull sources and build them in a place that other developers can reference.
You'll find that software reuse by way of header files and the linker is
far superior to sharing source code. The trade-off is that you need to
--- Forwarded mail from [EMAIL PROTECTED]
Thank you for the responses...
On Wed, 31 Mar 2004, Paul Sander wrote:
Some shops also implement a handoff mechanism that divorces the notion
of latest committed from candidate for integration. That allows
the developers to commit with impunity
--- Forwarded mail from [EMAIL PROTECTED]
Derek Robert Price [EMAIL PROTECTED] writes:
Mark D. Baushke wrote:
The `cvs log' output is definately not designed to be machine
parsable, as you would likely know if you have ever tried to parse it.
I have many thounsands of lines of perl, gawk
--- Forwarded mail from [EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf
Of Satish Talim
Sent: Monday, March 22, 2004 8:16 AM
To: [EMAIL PROTECTED]
Subject: 2 CVS servers
My client based abroad has a Linux based CVS server on which
ClearCase does indeed have this capability.
CVS does not, but you can fake it out in a couple of ways. The first is
to perform multiple checkouts, pulling the various directories from the
right branches. Another is to play games with your branch tags so that
different branches are pulled with
--- Forwarded mail from [EMAIL PROTECTED]
- Original Message -
From: Derek Robert Price [EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dennis Jones wrote:
Along the lines of Andy Jones' Tagging across branches thread posted
earlier today, I have a similar
It sounds like the gvim program is launching your edit session in the
background and then exiting. You can create the same effect with vi
by using the following script as your editor:
#!/bin/sh
xterm -e vi $1
CVS relies on the exit of the editor process as a signal that the
--- Forwarded mail from [EMAIL PROTECTED]
-kb or not, I think this brings up what amounts to a bug or yet another
instance of surprising and unexpected behavior which needs to be killed.
I don't think you've considered all the funny cases that come into play
when deleting/undeleting/branching
Commit will complain that the workspace is not up to date, and update
will complain about a local mod/remote deletion conflict. Recovery is
for the user to either do a cvs add to resurrect the file or cvs rm
to remove the file, and commit.
--- Forwarded mail from [EMAIL PROTECTED]
Can a
You should be able to make something out of the rinfo program, which
much of the same information as rlog, but in a format that's easier to
scan and reformat into what you want. It's located at:
http://www.wakawaka.com/source.html
--- Forwarded mail from [EMAIL PROTECTED]
How can I generate a
Chances are you're using the default common ancestor for each merge. The
3-way merge algorithm then rediscovers each change made cumulatively on both
branches each time. The solution is to specify the result of the last merge
as the common ancestor when you run cvs update. For that, you must
--- Forwarded mail from [EMAIL PROTECTED]
Schrum, Allan (Allan) writes:
Tar has a limit on the max length of the filenames it will archive. Cpio
does not seem to have that limit.
Traditionally, both tar and cpio have limitations, they're just
different. Various enhanced versions of the file
--- Forwarded mail from [EMAIL PROTECTED]
At 4:07 AM -0500 2/12/04, m0llbuz_ wrote:
I also get weird conflicts during merges where the diffs are exactly the same.
foo.pm
foo
=
foo
1.2.2.1
I've seen this too. Are there white space differences? Or were the
two lines adde in
--- Forwarded mail from [EMAIL PROTECTED]
1- Merge the branch to the trunk each time a bug fix is done on
the branch, resolving (an increasing number of) conflicts
as they appear (no real need for merge tags in this case); or
Merge-as-you-go is the best approach. It minimizes
Have you considered a variation on method 1? Consider this:
Before beginning work on a bug fix, apply a tag to the affected files. (You
can tag everything in the containing directory if it's easier). Then fix
the bug. Then merge the bug fix to the trunk, using the tag as the common
ancestor.
You might also take a look at Monotone:
http://www.venge.net/monotone
--- Forwarded mail from [EMAIL PROTECTED]
Take a look at CVSUp - there may be others as well.
http://www.cvsup.org/
CVSup is a software package for distributing and updating collections
of files across a network. It can
I think that someone added a file to CVS in a way that didn't involve
typing the name of the file. People should really avoid naming files
with characters that are not printable ASCII. Theoretically it shouldn't
matter, but CVS is known to get indigestion when file names contain white
space.
Does the somefile exist in the repository, either in a container directory
or an Attic directory? I would expect something like this if someone rm's
an RCS (,v) file directly from the repository. Do other commands, such as
cvs status break with this file?
--- Forwarded mail from [EMAIL
--- Forwarded mail from [EMAIL PROTECTED]
On Sat, 13 Dec 2003, Paul Sander wrote:
I want to affect HEAD, just not for this one file. Making a branch
would be a bit silly if I will never commit anything on that
branch.
Not at all. Isolating your work from that of your peers is what
branches
Release 3.0 of Dick Grune's original CVS scripts were published to the
comp.sources.unix newsgroup, volume 22 issue 13. You can find them at
the following URL:
ftp://gatekeeper.research.compaq.com/pub/usenet/comp.sources.unix/volume22/cvs3.0/
Don't expect much in the way of the kind of
I've applied two approaches to address this problem that can be implemented
readily with CVS:
The first method is to use a personal branch for your own development and
periodically merge to the main branch. This is a standard pattern of use
in CVS.
The second is to divorce the notion of
There are private branches, and there are private branches. In the context
that you describe, the integration branch is private to the builders who
gate the release of the product. Jim refers instead to a branch that's
private to the developer performing the work.
Branches are a general tool
It can't be done unless you're willing to live with one of the following:
1. Old releases fetched by timestamp or tag get pulled with the new
organization.
2. Revision history is fragmented among multiple files, and cannot merge
between branches where one of the branches has been
There's a small incremental cost per tag per file: Each tag is represented
by a line in each RCS file. This is typically less than 100 bytes but
it depends on the length of the tag and the depth of the branch to which the
tag is applied. In terms of time, this amounts to probably a few
--- Forwarded mail from [EMAIL PROTECTED]
From: [EMAIL PROTECTED] (Paul Sander)
Date: Tue, 25 Nov 2003 14:34:00 -0800
CVS has no such option, but RCS does. The ci program, which creates a new
revision in a ,v file, can override the system time when storing a
timestamp. To use it, you
In addition to tagging, we also built a manifest of the source files,
checked it in, and applied the same tag as was applied to the rest of the
build. The manifest was stored separately from the source code so that
developers wouldn't muck with its tags. Our rebuild procedure used that
file to
CVS has no such option, but RCS does. The ci program, which creates a new
revision in a ,v file, can override the system time when storing a
timestamp. To use it, you must muck directly with the repsitory.
--- Forwarded mail from [EMAIL PROTECTED]
I have the job of transitioning a large
--- Forwarded mail from [EMAIL PROTECTED]
Lynch, Harold [EMAIL PROTECTED] writes:
This may be a wierd one.=20
=20
If there are two different repositories on one machine, would it be a
bad thing to link part of one repository to the other.
=20
I.E.
=20
if there is a module in repository A
--- Forwarded mail from [EMAIL PROTECTED]
Jim.Hyslop [EMAIL PROTECTED]
WeLl mAdE ArguMent...
No, not at all. For example, of the 111 items in my home directory
right now, 17 of them use upper-case letters in a meaningful
way. Common practice is to name some things on Unix in a mixture of
cases,
--- Forwarded mail from [EMAIL PROTECTED]
Steve McIntyre [mailto:[EMAIL PROTECTED] wrote:
Another point I'd like to make: labels are case-sensitive
already. Live with it.
I think you missed my main point: *why* should the user have to deal with
it? Just because that's the way it works? Well
Labels are not immutable; they can be moved around. Some shops deliberately
use floating labels, e.g. to identify the latest sources eligible for build.
This cuts down on clutter under several methodologies. Under such conditions,
pulling from a specific (floating) label may NOT pull the
--- Forwarded mail from [EMAIL PROTECTED]
Jim.Hyslop wrote:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] wrote:
Labels are not immutable; they can be moved around. Some
--[clip]--
Then the label should clearly indicate it's the latest version. A version
handed off to QA is not the latest
--- Forwarded mail from [EMAIL PROTECTED]
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] wrote:
Labels are not immutable; they can be moved around. Some
shops deliberately
use floating labels, e.g. to identify the latest sources
eligible for build.
Then the label should clearly indicate it's
The rename problem has been discussed at length in this forum, and
several methods have been discussed. I believe that the best way to
solve the problem is to add a layer of indirection in the translation
between working file and RCS file. The pointer to the RCS file would
be stored in a
--- Forwarded mail from [EMAIL PROTECTED]
[ On Tuesday, October 14, 2003 at 13:05:58 (-0400), Derek Robert Price wrote: ]
Subject: Re: locking entire tree for write
If nobody has any comments on this, I'm going to check in the correction
on feature soon.
| Correct me if I am wrong, but
Technically speaking, no history is lost. In practice, these actions are
not sufficient. If you have branches, then you may want to somehow replicate
some of them to the new location as well. CVS doesn't help with that at all.
Also, if you want to merge between branches in your before- and
CVS never assumes you want to move the file. In this case, it assumes
you want to remove a file from one place and add a new file in a different
place, because that's what you told it you want to do.
The only association made between the two files is in the user's mind and
maybe in comments
. It does not matter if you wait to commit
or commit the remove and then commit the add, the result is the same?
-Original Message-
From: Paul Sander [mailto:[EMAIL PROTECTED]
Sent: Monday, October 06, 2003 1:01 PM
To: Rod Macpherson; [EMAIL PROTECTED]
Subject: Re: CVS File Move
CVS never assumes
What I would have done is set up a cname record in my DNS configuration
to give a symbolic name (e.g. cvsroot) to the machine, in addition to
its regular host name. That way if the server moves around, then a
quick tweak to the DNS server will give all of the users access again
with no changes to
--- Forwarded mail from [EMAIL PROTECTED]
On Tue, 2003-09-09 at 12:12, Kaz Kylheku wrote:
On Tue, 9 Sep 2003, Tom Copeland wrote:
On Mon, 2003-09-08 at 16:00, Greg A. Woods wrote:
I can import gigabytes and terabytes of binaries into CVS too, but no
matter how much I try I'll never be
--- Forwarded mail from [EMAIL PROTECTED]
On Tue, 9 Sep 2003, Tom Copeland wrote:
On Tue, 2003-09-09 at 12:12, Kaz Kylheku wrote:
On Tue, 9 Sep 2003, Tom Copeland wrote:
On Mon, 2003-09-08 at 16:00, Greg A. Woods wrote:
I can import gigabytes and terabytes of binaries into CVS too, but
The rinfo program will parse the RCS files and provide info about each
revision. If you need something it doesn't give then it's easy enough to
add it.
Once you have mapped out the structure of the RCS files, you should be able
to simply use the co program with appropriate -k options to get what
The CVS design is not so married to the diff program that it could not be
swapped out at a low level for more appropriate tools. (Keep in mind that
somewhere in the CVS implementation it effectively invokes a diff or
diff3 command. That command could really be anything, as long as it's
--- Forwarded mail from [EMAIL PROTECTED]
Ronald Petty [EMAIL PROTECTED] writes:
When you do a cvs update -j branch_name, you see all the files in the
module fly by and it tells you whether there is a conflict or whatever.
Is there a way to do this (see what would happen), without it really
--- Forwarded mail from [EMAIL PROTECTED]
On Thu, Aug 07, 2003 at 06:42:43PM -0400, Dickson, Craig wrote:
Or alternatively is there a known algorithm, that given a
CVS revision number, can determine what the previous revision number was?
if the last component (the Z in 1.3.2.Z) is greater than
--- Forwarded mail from [EMAIL PROTECTED]
[ On Sunday, August 3, 2003 at 20:30:04 (-0400), Larry Jones wrote: ]
Subject: Re: Strange diff behavior on branch
Greg A. Woods writes:
It seems to me that it would be most logical and most elegant to simply
use the combination of '-r' and '-D'
--- Forwarded mail from [EMAIL PROTECTED]
[ On Thursday, July 31, 2003 at 07:47:09 (-0700), Mark D. Baushke wrote: ]
Subject: Re: Strange diff behavior on branch
I think that the -D timestamp is documented as doing timestamps on the
trunk rather than a branch at present. The right thing to
--- Forwarded mail from [EMAIL PROTECTED]
Frank Langtind wrote:
Our company is in the process of changing from RCS to CVS for revision
control and I'll need some advice to make it as good as possible.
Our work in divided in project groups that work with modules and project
groups that work
The rinfo program has a mode to display one-line summaries of ranges of
versions. Doing a line-count on its output should give you what you want.
Sources for the rinfo program are located at
http://www.wakawaka.com/source.html
Alternatively, you could try this:
cvs log -N -rver1::ver2 file |
--- Forwarded mail from Greg Woods:
[ On Thursday, June 5, 2003 at 14:00:12 (-0700), Kaz Kylheku wrote: ]
Subject: Re: .cvsignore file being ignored
I think that .cvsblock is silly; the tiny semantics difference between
that and .cvsignore is not worth it. The cvs add command should ignore
--- Forwarded mail from [EMAIL PROTECTED]
On Tue, 27 May 2003, Greg A. Woods wrote:
No concurrent versioning system with a shared repository, and
particularly not one that can operate in a client/server mode, can ever
possibly make any use of ownership, nor even of most permissions bits.
--- Forwarded mail from Greg Woods:
If you really want to do something to make merging of changes easier and
more reliable then I'd suggest working on merge tools that can identify
and copy changes at the syntactical level instead of on the card
(line) level.
--- End of forwarded message from
--- Forwarded mail from [EMAIL PROTECTED]
It's one hell of a lot easier to tell what's going on with conflicts if
you fix CVS to call diff3 in such a way that it includes the full
conflict information:
[context diff omitted]
This should have been changed years ago.
--- End of forwarded
--- Forwarded mail from [EMAIL PROTECTED]
[ On Sunday, May 25, 2003 at 19:51:07 (-0700), Paul Sander wrote: ]
Subject: RE: cvs add directory
The method you've described in the past depends on a linked structure
involving having users write special syntactic sugar in their commit
comments
--- Forwarded mail from Greg Woods:
[ On Sunday, May 25, 2003 at 19:51:07 (-0700), Paul Sander wrote: ]
Subject: RE: cvs add directory
I believe that developers must be permitted to check in their work
arbitrarily.
H Arbitrarily was perhaps the wrong word to use here.
THEN PLEASE
--- Forwarded mail from [EMAIL PROTECTED]
No concurrent versioning system with a shared repository, and
particularly not one that can operate in a client/server mode, can ever
possibly make any use of ownership, nor even of most permissions bits.
Ownership information, and most permissions
What Marc is describing is a different paradigm for change management.
Systems such as Aide-de-Camp track features, and when you want a workspace
you specify a set of features that you want.
There are limitations to such a system, as you would expect, but it is
viable approach.
--- Forwarded
The downside to the modules database is that it's not a first-class
citizen. It's not subject to the same handling as other versionable
objects in the repository (it's checked into an RCS file, but only the
head version is ever used). That means you can't change the definition
of a project over
I implemented such a system using CVS about 10 years ago, and it worked
quite well. There has been some discussion about it over time in this
forum. Search the archives for submit/assemble for details.
--- Forwarded mail from [EMAIL PROTECTED]
I would also be very interested in hearing other's
--- Forwarded mail from [EMAIL PROTECTED]
I will explain:
1) I have 2 directories inside CVSROOT with different names A and B.
2) I have a1,a2 files in A directory
3) I have b1,b2 files in B directory
4) I want that if i modify file a1, b1 should be modified automatically and
vice versa
My tool of choice for software reuse was the editor, until I inherited
60,000 lines of code from someone who felt the same way. Now my tool of
choice for software reuse is the linker. -- me, 1988
The solution to your problem is not to use CVS to model your subsystem
dependencies, but rather use
The advantage to chroot environments is that they can limit exposure to
things like rogue *info scripts that might reach beyond the CVS repository.
This is handy in the event that you store sensitive data on the machine
in addition to the repository.
The biggest argument in favor of user accounts
--- Forwarded mail from [EMAIL PROTECTED]
--- Paul Sander [EMAIL PROTECTED] wrote:
A chroot environment is only good at containing
what's inside it. It
does not prevent access to the chroot environment
from outside.
I see. I guess it's obvious that the repository would
have to be within
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,
I would be astonished if this were true. You'd have to replicate
/bin, /usr/bin, /etc, /lib, /usr/lib, /etc, /usr/local, /include,
/usr/include, /dev, and a whole lot of other stuff to make it work
at all. And even then, stuff like ps still won't work properly.
--- Forwarded mail from [EMAIL
This is a build issue that falls outside CVS' scope. But if you want
code reuse at the source level, you can use modules. If you want code
reuse at the library level, build a baseline and refer to it in your
build process. You can build references using environment variables,
symlinks,
--- 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 want to do more
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
--- 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 one
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.
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
--- 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. It is
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
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
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 sophisticated
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
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
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
--- 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
101 - 200 of 490 matches
Mail list logo
