>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 avai
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, a
>[[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,
>[[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, pser
>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 arc
>[ 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 consid
>> 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 technolo
>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 calculato
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 kno
>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 bac
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 CVS
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]>
>
> > T
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]>...
> > Andre
>[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 co
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 well
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/fileat
>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 o
The most you could hope for in CVS is to install a patch that allows
advisory locks -- reserved locks are counter to the purpose of CVS. You
can find a version of the patch (I think against cvs-1.11.1) at SourceForge
under project RCVS.
Once the patch is installed, tell the users that they must
The patch is available at SourceForge under project RCVS.
The gist of the patch is:
1. "cvs edit -c" will abort the edit if another is editing the files.
2. "cvs edit -f" will force the edit.
3. "cvs ci -c" will abort the checkin if a valid edit does not exist on
the files.
Noel
Does anyone
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=4680&atid=304680&file_id=6141&aid=422725
Noel
There are no files to download in this project. Looks DOA.
[EMAIL PROTECTED] wrote:
> The patch is available
>> 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.
Noe
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. C
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 mea
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 broke
>> 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 ch
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
I was able to use Netscape get to the patches. Exactly what are you doing?
Noel
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
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 benefi
>In the end, productivity is probably the same in either method.
Developers
>spend a lot of time getting coffee every day while their automatic merges
>complete, or they slave away for hours resolving conflicts once every
couple
>of weeks. But perception is everything here; letting the automati
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 referri
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 Nutscrape
37 matches
Mail list logo