>--- Forwarded mail from [EMAIL PROTECTED]
>Paul Sander writes:
>>
>> There's just one little problem with this: "cvs log" only works when
>> a file is in your sandbox. If it's been removed and committed, then
>> you must do something li
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Friday, February 22, 2002 at 13:25:37 (-0800), Paul Sander wrote: ]
>> Subject: Re: CVS Update Behaviour
>>
>> And every time a merge is done from a branch where a rename was done on
>> one of the branches.
>And
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Friday, February 22, 2002 at 14:45:32 (-0600), Steve Greenland wrote: ]
>> Subject: Re: CVS Update Behaviour
>>
>> On Fri, Feb 22, 2002 at 02:14:21PM -0500, Greg A. Woods wrote:
>> > [ On Friday, February 22, 2002 at 12:18:37 (-0600), Steve Greenla
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Friday, February 22, 2002 at 12:21:23 (-0800), Noel Yap wrote: ]
>> Subject: Re: renames under CVS
>>
>> If it's not necessary, then it's at least very nice to
>> have.
>How nice I've been trying to get actual metrics about this for
>years, a
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Friday, February 22, 2002 at 12:05:34 (-0800), Paul Sander wrote: ]
>> Subject: Re: CVS Update Behaviour
>>
>> I don't know about anyone else, but I use "cvs log" every time I do a
>> "cvs update&
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Friday, February 22, 2002 at 12:18:37 (-0600), Steve Greenland wrote: ]
>> Subject: Re: CVS Update Behaviour
>>
>> On Fri, Feb 22, 2002 at 01:16:35AM -0500, Greg A. Woods wrote:
>> > It's hardly even noticably
>> > more difficult to track the histo
On Solaris, it's more than a megabyte.
>--- Forwarded mail from [EMAIL PROTECTED]
>Does anyone know what the argv[] limit is for solaris 2.6? I have tested
>pserver with up to 50 --allow-root options being passed and seemed to work
>fine.
>--- Kaz Kylheku <[EMAIL PROTECTED]> wrote:
>> It's you
>--- Forwarded mail from [EMAIL PROTECTED]
>On Thu, 2002-02-21 at 21:03, Paul Sander wrote:
>> >--- Forwarded mail from [EMAIL PROTECTED]
>>
>> >[ On , February 21, 2002 at 18:55:21 (-0500), Arcin Bozkurt - Archie wrote: ]
>> >> Subject: Re: CVS Up
I won't comment on the mechanics of refactoring specifically, but I'll
try to answer your questions with regard to SCM artifacts. Refactoring
is another way of describing changes to the design of a project, which
is still largely an art form and it's an exercise for the developer to
determine whe
When you imported the latest sources, you applied two tags: The vendor
branch tag, and the vendor version tag. The import applied the vendor
version tag only to those files that were actually imported. Have you
tried applying the vendor version tag to the latest revisions of all
files on the ve
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Thursday, February 21, 2002 at 18:03:20 (-0800), Paul Sander wrote: ]
>> Subject: Re: CVS Update Behaviour
>>
>> That last paragraph is utter crap. Without having the entire history
>> of a file's lifetime in o
>--- Forwarded mail from [EMAIL PROTECTED]
>In article <[EMAIL PROTECTED]>, Paul Sander wrote:
>>>--- Forwarded mail from [EMAIL PROTECTED]
>>
>>>>>>>> "Paul" == Paul Sander <[EMAIL PROTECTED]> writes:
>>>Pau
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On , February 21, 2002 at 18:55:21 (-0500), Arcin Bozkurt - Archie wrote: ]
>> Subject: Re: CVS Update Behaviour
>>
>> On Thu, 2002-02-21 at 17:45, Greg A. Woods wrote:
>> >
>> > Don't get stuck on this idea of trying to keep track of everything back
>--- Forwarded mail from [EMAIL PROTECTED]
>>>>>> "Paul" == Paul Sander <[EMAIL PROTECTED]> writes:
>Paul>
>Paul> Unfortunately, if this is what your build procedure consists of,
>Don't be silly. We have our own make tool (written
>--- Forwarded mail from [EMAIL PROTECTED]
>> "David" == Thornley, David <[EMAIL PROTECTED]> writes:
>David>
>>> -Original Message-
>>> From: Noel Yap [mailto:[EMAIL PROTECTED]]
>>> > Refactoring in C could just as easily leave you with
>>> > a whole lot of
>>> > deleted files and a
>--- Forwarded mail from Greg Woods:
>[ On Tuesday, February 19, 2002 at 15:40:15 (-0800), Paul Sander wrote: ]
>> Subject: RE: Converting ClearCase to CVS
>> There's no doubt that many freeware projects, some of them large, benefit
>> greatly from the use of CV
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Tuesday, February 19, 2002 at 18:04:06 (-0500), Eric Siegerman wrote: ]
>> Subject: Re: Converting ClearCase to CVS
>>
>> On Tue, Feb 19, 2002 at 05:04:54PM -0500, Greg A. Woods wrote:
>> > Without knowing details of either sitution I think you hav
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Tuesday, February 19, 2002 at 11:58:34 (-0800), Paul Sander wrote: ]
>> Subject: RE: Converting ClearCase to CVS
>>
>> Let's assume for the sake of argument that your salary is around $40/hour.
>> For $8000,
For each file that you want to tag, lop off the penultimate decimal point
from the branch number (and everything following it). The result is the
sprout point of the branch. If your repository combines CVS branches with
RCS branches, then use the .1 version on the branch rather than the branch
n
>--- Forwarded mail from [EMAIL PROTECTED]
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>> Sent: Tuesday, February 19, 2002 12:45 AM
>> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
>> Subject: RE: Converting ClearCase to CVS
>>
>> First of all, I am a CVS exper
Starting to get off-topic and long-winded, but I can't let this go. Sorry!
>--- Forwarded mail from [EMAIL PROTECTED]
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>>
>> >[ On Saturday, February 16, 2002 at 12:4
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Saturday, February 16, 2002 at 12:42:57 (-0800), Paul Sander wrote: ]
>> Subject: Re: Converting ClearCase to CVS
>>
>> You get what you pay for. In my opinion, the quality of implementation
>> of ClearCase is
>--- Forwarded mail from [EMAIL PROTECTED]
>--- "Mark A. Flacy" <[EMAIL PROTECTED]> wrote:
>> Out of curiosity, why are you moving from ClearCase to CVS?
>Okay, you asked. Here it comes. But my question would be why not move from
>ClearCase to CVS? This comes from my personal experience at multi
>--- Forwarded mail from [EMAIL PROTECTED]
>> 2) CVS can't automatically merge changes. This matters more or
>> less depending on (a) how frequently the files change (hence
>> the gif vs. spreadsheet discussion), and (b) how hard it is
>> to merge changes manually, or through se
Oops, my previous post referred to a script that collects a bill of
material, which was omitted. Here's one that I quickly threw together,
updated for CVS v1.10 and later. Its command line lists directories in
which bills of materials are gathered, with recursive descent. If no
command line ar
er of discussions about it over the
years. Here are a couple of messages that convey most of the substance.
+++
Date: Fri, 1 Nov 96 21:07:39 PST
From: [EMAIL PROTECTED] (Paul Sander)
Message-Id: <[EMAIL PROTECTED]>
>How do most CVS users control what goes into each official buil
idea is that
the HEAD branch *must* always build (at least after a short period
(hours max) of instability). So multiple dev branches for big
collaborative changes is the method that seems to work best for me.
Paul Sander wrote:
>Another approach that doesn't require developers to p
Another approach that doesn't require developers to perform as many merges
is to implement a hand-off procedure that declares certain versions as
eligible for the build. This can be as simple as applying tags, or it could
be more complicated. That way, the developers and the builders can share
t
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Friday, January 25, 2002 at 11:30:27 (-0800), Paul Sander wrote: ]
>> Subject: Re: ANN: cvssh - secure ext-to-pserver bridge
>>
>> CVS' pserver mode implements its own security. It's up to the CVS
>>
>--- Forwarded mail from Greg Woods:
>[ On Friday, January 25, 2002 at 00:24:31 (-0800), Paul Sander wrote: ]
>> Subject: Re: ANN: cvssh - secure ext-to-pserver bridge
>>
>> Applications don't require Unix user IDs to track their own user
>> bases.
>Yes,
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Wednesday, January 23, 2002 at 22:56:35 (-0800), Paul Sander wrote: ]
>> Subject: Re: ANN: cvssh - secure ext-to-pserver bridge
>>
>> When someone uses shared accounts, they throw away Unix security. Maybe
>> that&
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Wednesday, January 23, 2002 at 20:02:55 (-0800), Paul Sander wrote: ]
>> Subject: Re: ANN: cvssh - secure ext-to-pserver bridge
>>
>> What I don't understand is why it's necessary to give people accounts on a
&g
>--- Forwarded mail from Greg Woods
>> 2. Using SSH requires giving the users a unix account on
>>the server, rather than pserver's per-repository user
>>list.
>Duh. If you're doing authentication and authorisation on a unix-based
>file server then you MUST, _M_U_S_T_ use a unique syste
Have your sandboxes been updated to reflect the new version number after
the commit? I've seen cases with CVS in which a person would commit code
successfully, see in his sandbox (with "cvs status") that the file is up
to date, and then find that the new version is missing when running
"cvs log".
Unfortunately, CVS has no provision to query for tags applied to any
file that appears in the user's sandbox. Someone would have to write a
special tool for this, assuming the file is left in a sandbox (as opposed
to, say, being exported).
An alternative that also depends on a sandbox is to use
Following is a demonstration-quality patch to show how CVS can be modified
to replace its existing merge capability with an extensible mechanism
that can be configured to handle merging in any way the CVS admin sees
fit. What happens is that CVS' invocation diff3 to perform the merge is
replaced
Have you looked at rinfo? It does what you ask, for a single RCS file.
You'd have wrap it in a script that traverses your repository to see all
changes in your project. You could also combine it with lmerge to produce
more concise reports.
Both of these programs are available at http://www.waka
Why not build these features into CVS directly? It'd save an enormous
amount of runtime overhead.
--- Forwarded mail from [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Matthew Herrmann wrote:
>hi all,
>
>what do people think about the idea of a project which sits on top of cvs
>and provides
I had a similar problem once, and I couldn't solve it without modifying
CVS. Our solution was to use CVS in local mode (i.e. use NFS for network
access), and set permissions on the repository so that members of the A
group had read/write access to module A, members of the B group had read/write
a
>--- Forwarded mail from [EMAIL PROTECTED]
>My company is currently using CVS to manage some third-party vendor
>really big, big tree with really many, many very big, big files.
>The result, obviously, is totally unacceptable. Even one of this
>files may take something like half an hour to chec
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Tuesday, December 18, 2001 at 20:00:54 (-0800), Paul Sander wrote: ]
>> Subject: RE: Possible modifications to CVS.
>>
>> It's also a required feature if you're migrating from one well-organized
>> structure
>--- Forwarded mail from [EMAIL PROTECTED]
>I setup a CVS server (version 1.10.6) a while back, and I now have the need
>to share some files between projects.
>The files are test data that does not change between projects, so I do not
>want to duplicate it in the repository.
>Previously, I used V
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Tuesday, December 18, 2001 at 13:30:23 (-0600), Thornley, David wrote: ]
>> Subject: RE: Possible modifications to CVS.
>>
>>
>> So, I figure that that would be a nice capability that isn't
>> going to happen in CVS.
>It is only a "nice" capabili
>--- Forwarded mail from [EMAIL PROTECTED]
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>>
>> [EMAIL PROTECTED] writes:
>> > If this isn't possible, I would suggest it be added to
>> CVS. What I would
>> > like to see is a way to check out files from an
>--- Forwarded mail from [EMAIL PROTECTED]
> As a CVS administrator, How can we maintain modules/directories/files
>when we have environments like production, stage and Development.
>I mean once Developers develop some code, test it and then I want to keep
>these files or code in the production
I have successfully used Gnu RCS on RCS files created by MKS RCS. Two
points: You may have to rename the RCS files to be compatible with Gnu,
and Gnu won't work if the RCS file contains binary data. You should be
fine if the contents of the RCS file is ASCII text.
--- Forwarded mail from [EMAI
Another approach that has been used successfully is to supply some tools
that collect state from the CVS/Entries and CVS/Repository files and store
them in a separate database as a change list to be applied to an existing
baseline. The system works best if there's a manifest collected for the
bas
>--- Forwarded mail from [EMAIL PROTECTED]
>Robert Thorpe writes:
>>
>> What you are saying is that I should make a pointless alias in the
>> modules file to the modules in question and whenever I wish to
>> create a new module I must do the same.
>It's not pointless, it allows co -c to provi
The last sentence indicates a reasonable requirement to have the
"cvs annotate" command do something reasonable with binary files.
Perhaps it could produce a diagnostic that says "Can't annotate a
binary file", which is much more reasonable than hanging.
>--- Forwarded mail from [EMAIL PROTECTED]
On September 16, 2001, I posted a patch to CVS that replaced its built-in
merge algorithm with an extensible mechanism. The context of that patch
was to provide better merge support for non-ASCII files, but it would
serve your needs quite well also.
Search an archive of this list for the followi
Sorry for the off-topic posting, but as CVS admins are often interested
in storage management issues, this could be of use to many of you.
The dirq package provides a couple of tools that help with storage
management by implementing queues of directories. Directories may also
have state assigned
Have you looked into using -ko for this purpose?
--- Forwarded mail from [EMAIL PROTECTED]
By the way, the reason I'm using -k 'b' is so that there is no
substitutionbut these should be all mergeable text files.
--- End of forwarded message from [EMAIL PROTECTED]
_
I don't know of a way to do it with the CVS command line, other than to
parse the output of "cvs log". But if you have a list of RCS files and
direct access to the repository then you could use rinfo to get the
commit commentary for a range of versions within each file, then use
lmerge to elimina
>--- Forwarded mail from [EMAIL PROTECTED]
>> -Original Message-
>> From: Jerry Nairn [mailto:[EMAIL PROTECTED]]
>> Sent: Monday, November 26, 2001 4:34 PM
>> To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
>> Subject: RE: Can we find all the branches on a module through some
>> script?
>>
>>
--- Forwarded mail from [EMAIL PROTECTED]
>I would like to know the statistics on a particular file ( say test.c
>) from one version to another version ( say from 1.2 to 1.7 ).
>So for instance if i run the command/script
> -R1.2 -R2.7 test.c
>i would like to know the number of lines added, de
I'd like to announce the availability of rinfo v1.5. The rinfo program
displays RCS metadata in a format that can be scanned automatically in
a more robust way than the output of the rlog (or "cvs log") commands.
This version adds the ability to specify tags or labels as version numbers
when ide
>--- Forwarded mail from [EMAIL PROTECTED]
>"Lars-Christian Schulze" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> TkCVS has a parser for the logfile, which extracts the log message, tags
>> etc. and builds a nice revision tree. Maybe you can extract and use some
>> of the
>--- Forwarded mail from [EMAIL PROTECTED]
>Sau Dan Lee <[EMAIL PROTECTED]> wrote:
>>
>> For your case, I think you'll be better of saving the binary
>> files with names containing version numbers (manually assigned).
>> There is no space lost with this method (since there is no generic
The uuencode format is an example of an ASCII-but-unmergeable format.
In other words, after you've performed a merge between two or three
uuencoded files, the output will likely be unrecognizable by the
uudecode program.
You're better off using something that's better suited to storing
binaries.
In that case, take a look at the -o and -u options that can be used
in the modules database. These features are pretty gunky but they might
fill the bill by allowing you to register programs to execute during
checkout and update. The downside is that they drop cookies in your
sandbox that can't
>--- Forwarded mail from [EMAIL PROTECTED]
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>> Sent: Friday, October 12, 2001 4:28 PM
>> To: [EMAIL PROTECTED]
>> Subject: Handling project documentation using CVS
>>
>>
>> Hello all, I was wondering if some of y
>--- Forwarded mail from Greg Woods:
>[ On Sunday, October 14, 2001 at 01:49:56 (-0700), Paul Sander wrote: ]
>> Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs]
>>
>> Assuming that some kind of rename capability is built into CVS that
>> stores additional me
Make a distinction between modules and subsystems. For this, I'll use
SA to mean "subsystem A", SB to mean "subsystem B" and so on.
Create modules for each subsystem:
subsystem-A src/A
subsystem-B src/B
subsystem-C src/C
subsystem-D src/D
Then create your modules to contain the
Do you really believe that overloading symbolic tags is a good idea?
What value do you set the special tags to? Are users allowed to modify
them with the usual tag commands? Do you want users to see them with the
usual log commands? Do you want to prevent users from using them as
version select
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Saturday, October 13, 2001 at 12:34:03 (-0700), Paul Sander wrote: ]
>> Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs]
>>
>> Greg A. Woods wrote:
>> >
>> > [ On Friday, October 12, 2001 at 20:34:48 (-
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Friday, October 12, 2001 at 20:34:48 (-0700), Paul Sander wrote: ]
>> Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs]
>>
>> They can be stored in newphrases inside the RCS files, without breaking
>> compatibility
>--- Forwarded mail from [EMAIL PROTECTED]
>CVS cannot easily ever support renaming to any extent that something
>like BitKeeper or Perforce does, at least not without breaking backwards
>compatabilty of the repository structure.
>There's simply no place to put the extra meta data necessary exce
>--- Forwarded mail from [EMAIL PROTECTED]
>In article <[EMAIL PROTECTED]>, Paul Sander wrote:
>>>--- Forwarded mail from [EMAIL PROTECTED]
>>
>>>[ On Thursday, October 11, 2001 at 23:12:44 (-0700), Paul Sander wrote: ]
>>>> Su
I think the original poster was referring to access controls on the
primitive operations allowed on files by the version control system,
e.g. some users are not permitted to commit on certain branches,
others are not permitted to create tags, and so on.
>--- Forwarded mail from [EMAIL PROTECTED]
>--- Forwarded mail from [EMAIL PROTECTED]
>3 developers (A,B,C) need to fix file X.
>A is making some major changes, adding lots of new functionality.
>B and C need to make a minor tweak to the file.
>In a CVS model:
>B anc C can be done and outa there in minutes and essentially forget about
>
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Thursday, October 11, 2001 at 23:12:44 (-0700), Paul Sander wrote: ]
>> Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs]
>>
>> >--- Forwarded mail from Greg Woods:
>> >Let me repeat: You DO NOT wan
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Thursday, October 11, 2001 at 23:08:38 (-0700), Paul Sander wrote: ]
>> Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs]
>>
>> I gain the requirement of having to type multiple "cvs log" or "cvs rlog"
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Friday, October 12, 2001 at 04:05:42 (GMT), Bryon Lape wrote: ]
>> Subject: Re: CVS - setup reserved checkout
>>
>> The benefits add up to zero. Now, if it did method locking, that would be helpful,
>> protective AND productive. Without some sort
>--- Forwarded mail from Greg Woods:
>[ On Thursday, October 11, 2001 at 20:06:18 (-0700), Paul Sander wrote: ]
>> Subject: Re: cvs exit status
>> And your point is what? That it's okay to sometimes let nondeterministic
>> errors go undetected? Sorry, that's
One would hope that one's shop is not using the same branch for both
maintenance and new features. That kind of thing is best done on
separate branches (where the two schedules don't interfere with each
other). The bug fix is later merged into the new development when
it's appropriate to do so.
D]
>Netscape tries and tries, but nothing is ever returned by this link.
>Paul Sander wrote:
>> Ich funde es bei
>http://sourceforge.net/tracker/index.php?func=detail&aid=422733&group_id=4680&atid=304680
>--- End of forwarded message from [EMAIL PROTECTED]
___
>--- Forwarded mail from Greg Woods:
>[ On Thursday, October 11, 2001 at 05:44:16 (GMT), Kaz Kylheku wrote: ]
>> Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs]
>>
>> In article <[EMAIL PROTECTED]>, Greg A. Woods wrote:
>> >> * 'cvs log BAR' does not list changes in file FOO
>> >
>> >Of cou
>--- Forwarded mail from Greg Woods:
>[ On Thursday, October 11, 2001 at 01:59:20 (-0700), Paul Sander wrote: ]
>> Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs]
>>
>> And not only do you lose the ability to get a file's entire version
>> history with
Ich funde es bei
http://sourceforge.net/tracker/index.php?func=detail&aid=422733&group_id=4680&atid=304680
>--- Forwarded mail from [EMAIL PROTECTED]
>Wo? Ich kann nicht es gefunden.
>Paul Sander wrote:
>> There's Noel Yap's patches on SourceForge, wh
There's Noel Yap's patches on SourceForge, which apply to a down-rev release
of CVS. I believe that others have implemented it as well, but only privately
in their own shops. Maybe they don't advertise them for fear of being blasted
by Greg.
--- Forwarded mail from [EMAIL P
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Thursday, October 11, 2001 at 15:48:53 (-0700), Paul Sander wrote: ]
>> Subject: Re: cvs exit status
>>
>> # Overflow occurs here; an exit status less than 258 indicates an overflow.
>> cvs update
>> echo &qu
If your question really is: "Is anyone modifying CVS to support locking?"
Then I believe the answer is "yes".
If your question really is: "Is anyone making locking a mainstream feature
of CVS?" Then I believe the answer is "no".
Despite the outcry to have this capability, no one with commit a
>--- Forwarded mail from Greg Woods:
>[ On Wednesday, October 10, 2001 at 14:43:14 (-0700), Paul Sander wrote: ]
>> Subject: Re: cvs exit status
>>
>> What happens on a Unix system when the exit status exceeds 127? It overflows.
>Well, actually it'll depend on
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On , October 10, 2001 at 17:31:23 (-0400), Sam Steingold wrote: ]
>> Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs]
>>
>> if you rename FOO to BAR "the right way", i.e.,
>>
>> $ mv FOO BAR
>> $ cvs rm FOO
>> $ cvs add BAR
>> $ cvs ci BAR
>>
>>
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Wednesday, October 10, 2001 at 14:40:11 (-0700), Paul Sander wrote: ]
>> Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs]
>>
>> In one method, you lose the ability to get a file's entire revision history
>>
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Wednesday, October 10, 2001 at 10:57:50 (-0700), Paul Sander wrote: ]
>> Subject: Re: cvs exit status
>>
>> Under some error conditions, the exit status gets incremented rather than
>> being set to a fixed value. Tha
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Wednesday, October 10, 2001 at 10:52:04 (-0700), Paul Sander wrote: ]
>> Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs]
>>
>> Generally speaking, renaming stuff in CVS is royal pain. You always lose
>> someth
Under some error conditions, the exit status gets incremented rather than
being set to a fixed value. That means that under those error conditions,
the exit status varies and may sometimes indicate success (due to overflow)
if there are a lot of problems.
So, exit status is not a reliable way to
Or, you could copy the ,v file to the new location and move the original
to the Attic. (Well, that's true if the rename is on the trunk. If it's
on a branch only, don't move to the Attic.) That at least leaves the
original version history in its original location. The downside that, of
course,
Of course, an alternative would be not to encrypt individual deltas but
rather the entire RCS file. The user would then be required to somehow
supply the key to whatever low-level software performs that function before
having any kind of meaningful access to the data.
It's not difficult to build
I have also personally experienced a situation with NetApp servers
where under heavy load a rename(a,b) call became an unlink(b) call,
which caused new committed data to be silently lost. It's been a
number of years since this has happened, but keep an eye open for
it.
>--- Forwarded mail from [
There's also the standard Unix "crypt" routine, and the source code to
the passwd program is available in any Linux and BSD distribution.
>--- Forwarded mail from [EMAIL PROTECTED]
>Mudit Sachdev wrote:
>> Hi Anyone know of a routine I can use to create a password file on
>> Sun Solaris system?
>--- Forwarded mail from [EMAIL PROTECTED]
>[Paul Sander - Wed at 11:05:05AM -0700]
>> >According to the ACL discussion, CVS is not a security tool, hence it would
>> >be very hard to make anything else than advisory locks.
>>
>> CVS, like any other applicati
>--- Forwarded mail from [EMAIL PROTECTED]
>[Paul Sander - Mon at 07:15:45PM -0700]
>> >2. If so, is there a way to make CVS use exclusive file locks - a la RCS &
>> >SCCS?
>>
>> There is a patch that changes CVS in such a way that with selected fil
>--- Forwarded mail from [EMAIL PROTECTED]
>Some questions:
>1. Does it make sense for us to use CVS on binary files?
CVS doesn't support binary files well out of the box. There exists a
patch that allows CVS admins to register new merge tools based on naming
conventions, but that code is not
The "cvs log" command has a "-r" option that can limit the amount of
stuff that it retrieves. It's output still requires some processing to
get what you want, though.
If you have access directly to the CVS repository then you might look
at the rinfo program at http://www.wakawaka.com/source.html
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Tuesday, September 25, 2001 at 17:06:43 (-0700), Paul Sander wrote: ]
>> Subject: Re: File permissions
>>
>> There's nothing wrong with adding meta-data.
>Well, it all depends on what the meta data is, and what u
>--- Forwarded mail from [EMAIL PROTECTED]
>On Tue, Sep 25, 2001 at 03:47:57PM -0400, Greg A. Woods wrote:
>> [ On Tuesday, September 25, 2001 at 21:08:59 (+0400), Tobias Brox wrote: ]
>> > Subject: File permissions
>Kaz Kylheku recently took up my challenge to give *valid* reasons
>not to track
>--- Forwarded mail from [EMAIL PROTECTED]
>[Greg A. Woods - Tue at 03:47:57PM -0400]
>> There's no way to handle _any_ file attribute change tracking without
>> extending the RCS file format. Period.
>When PreservePermission is set, the information is actually written to the
>RCS files. Is th
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Friday, September 21, 2001 at 00:44:42 (-0700), Paul Sander wrote: ]
>> Subject: Re: renaming a directory in the checkout / recursive add and commit for
>all subdirs
>> >hint: try "cvs log a/b/a.c" You wi
301 - 400 of 571 matches
Mail list logo
