I think you've pretty much listed all your options, however, note that
modifying the CVS/fileattr files can be automated making it not-so-tedious.
Noel
A developer has left our company. I deleted his account and all that.
But he is still mentioned hundreds' of times as editor and/or watcher of
Oh, I forgot, there's a patch against cvs-1.11 available at SourceForge
under project RCVS that'll add a -e editor option to cvs unedit. If
the user hasn't done cvs watch (eg only cvs edit), this patch may help.
I still think, though, that the easiest thing to do is modify the
CVS/fileattr
No, it is not. I think you need to figure out why the manager doesn't want
to use concurrent development models especially if the advisory locks patch
is installed to better control the process.
Noel
David Masterson [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Andrew
[EMAIL PROTECTED] (Kaz Kylheku) wrote:
Tell the manager to shed his or her superstitions, and work with
the facts. The facts are:
- Concurrent development works just fine.
- Your team already likes it.
- Strict locking does not prevent concurrency, it only reduces
it to a coarse
A huge portion of Streamed Lines deals with branches. Now, consider that
unreserved checkouts are sort of like (if not exactly) virtual branches...
IOW, if the manager is _really_ against concurrent development, then he/she
should be against any version control tool that allows branches as
I sent out instructions within the several threads about this. I guess you
missed it 'cos you were too busy ranting. Please check the archives.
Noel
How does one use the reserved locks?
Jerzy Kaczorowski wrote:
- Original Message -
From: Paul Sander [EMAIL PROTECTED]
There's
Because there is no group, and there are no conflicts. This is just
another Chicken Little yelling that the sky is falling. Actually
a step beneath Chicken Little, because something actually did fall on
Chicken Little's head, it wasn't just pure imagination. :)
Yes, I was giving him the
I got the same impression David and Greg did. Method locking is something
Envy in Visual Age has. Although I've never tried it myself, I think, at
least for Java, it's fitting s square peg into a round hole since Java, by
definition, is file based.
Noel
I think the original poster was
OK, then exactly what are you expecting from the link? Maybe SourceForge
was down when you tried it? Have you tried it again? Have you tried
following the step-by-step instructions I sent out?
Noel
I simply clicked on the link you supplied. I even copied it to IE just to
make sure
I got the link through clicking. I think you're doing something wrong.
Can you explain all the steps you're taking?
Better yet, I'll tell you how I got to the patches:
1. User your browser to go to http://www.sourceforge.com/
2. Enter RCVS into the search field
3. Click on Renegade CVS
4.
It sounds like the software your group is maintaining needs factoring to
decrease the likelihood that several developers are modifying the same
method. It also sounds like your group can use some communication.
Noel
Greg A. Woods wrote:
Read Berliner's whole paper. Understand what it means
If you've really made up your mind then don't use CVS. But think about
this first: Why are you the only group I know who has tried parallel
development and didn't like it?
Noel
*** REPLY SEPARATOR ***
On 11/10/2001 at 23:03 [EMAIL PROTECTED] wrote:
Read Berliner's whole
Then spend time doing the merge by hand and having to
possibly to ahold of the programmer who made other changes to make sure
everything
is done correctly. Now two programmers, at least, are being unproductive
and
costs are going up.
Don't you have regression tests to check if you've broken
Conflicts are extremely easy to produce and may not be easily resolved.
The issue it seems you are having is that on a regular basis, two or more
developers making large abouts of unrelated changes to same sections of
code.
This problem cannot be solved by locking checkouts, or by any change
You need to ask yourself why your group is experiencing so many conflicts
while so many other groups (thousands?) are not.
Noel
Kaz Kylheku wrote:
CVS doesn't require hand merging. When you perform a cvs update
operation, then new changes in the repository are automatically
incorporated
The patches are there for anyone to use. Last I heard, all that's stopping
them from being included with the standard distribution are the lack of
test and doc patches. You're welcome to work on them. Welcome to the
world of open source.
Noel
The RCVS part on source forge seems to be dead.
I don't know what you're talking about. I was able to get the reservations
patch at
http://sourceforge.net/tracker/download.php?group_id=4680atid=304680file_id=6141aid=422725
Noel
There are no files to download in this project. Looks DOA.
[EMAIL PROTECTED] wrote:
The patch is available at
If your question really is: Is anyone making locking a mainstream
feature
of CVS? Then I believe the answer is no.
shame
I think getting real reserved locks into CVS is impossible without
chainging CVS so much as to make it not CVS anymore. Of course, you're
welcome to try.
Noel
This
IIRC, edit keeps track of edits on a per file basis. I think many things
would have to change for it to track edits sn a per branch basis (eg What
if the branch gets redefined? Some users would care about other branches.
There might be others.)
Noel
I seem to have encountered an oddity in
I starting to think the best security doesn't base or rely on security
through obscurity. However, obscurity can strengthen security to an
extent. For example, how many of us are able to obtain Air Force One's
flight path at any given moment? Security is strengthened when the enemy
doesn't
3. A user would need to wait till the datalink is up before being able
to 'cvs watch' or 'cvs edit' a file. The user would need to keep
manual records of which files need to be watched or edited once the
datalink becomes available.
I think CVS buffers this information until the link is back
Still, it seems like a lot of banks actually can afford to lean on
security
by obscurity.
That's because they're in a position of authority and their customers do
not question their declarations (often because of course they do not
have the expertise to do so, especially in technologically
The only secure banking system I've seen used such a device for creating
one-time codes, but it wouldn't rely on a session, it would require the
user
to enter the code for _each_ transaction that was to be performed. That's
quite secure. But then again, what's the point, when the calculator
Yes - love the idea of pserver keeping usernames / passwords independant
of
the OS, and keeping cvs running as non-root.
I'm not sure if this is possible since I haven't tried it out myself, but I
think you can have each user have their own SSH keypair into a shared
account on the CVS server.
Read only users need write permissions into the directories where locks are
created (see LockDir configuration). They also need read permissions to
the repository directories and archives.
Noel
Still - security through obscurity /is/ better than no security at all!
Nope, not true at all. Security by obscurity leads to a false sense of
security, and as pretty well every rational sane person in North America
should realise by now there's really nothing worse than a false sense of
[ On Wednesday, September 26, 2001 at 17:01:25 (-0400),
[EMAIL PROTECTED] wrote: ]
Subject: Re: CVS access control
By definition, security is about preventing malicious users from
doing
harm. It's not about avoiding accidents by careless users. For
example,
would you consider a knotted
The problem is that, among a lot of public files (mode 644), there is
some
few secret files (mode 600). cvs add will silently ignore any file
permissions and make the ,v-file world readable (mode 444).
I can think of four solutions to the problem:
1. Keep files that need to be available to
Personally, I'm against the idea that CVS implement its own directory-level
ACLs -- this is a file system issue.
If one were to be developed, though, the interface (eg set and get ACLs)
should default to using file system ACLs if available. If file system ACLs
aren't available, I would prefer
When you're at it, you should also allow for different ruling on different
branches, not only directories.
I've been into the need for having write-permission (and it's a nice idea
in
general) only to the a particular sandbox branch of a project.
That would be a nice feature in CVS, also
[[EMAIL PROTECTED] - Wed at 10:45:50AM -0400]
I'm kind of against this, too, since branch-level permissions don't
afford
security at all since the archive file is still writable.
The pserver method is, as for now, the only one that can offer any real
access controls. As I understood, cvs
[[EMAIL PROTECTED] - Wed at 01:23:12PM -0400]
The pserver method is, as for now, the only one that can offer any real
access controls. As I understood, cvs users could only access the box
in
question through cvs.
I see nothing wrong with SSH. Also, from what I've heard, pserver is
not
On Wed, Sep 26, 2001 at 10:45:50AM -0400, [EMAIL PROTECTED] wrote:
When you're at it, you should also allow for different ruling on
different
branches, not only directories.
I'm kind of against this, too, since branch-level permissions don't
afford
security at all since the archive file is
33 matches
Mail list logo
