Riley Williams wrote:
> Hi Derek.
[...]
> >
> > Brian Behlendorf tells me that Collab Net will be supporting the
> > bandwidth and hardware for cvshome.org for an indefinite period.
>
> Are you sure of this? As of yesterday morning, I've been unable to get
> to cvshome.org either by web or cvs
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> [ On Friday, July 13, 2001 at 14:20:07 (-0500), Cameron,
> Steve wrote: ]
> > Subject: RE: How well does CVS handle other types of data?
> >
> > Re-reading my original message, I see I failed to mention
> t
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>
> [ On Friday, July 13, 2001 at 08:39:09 (-0500), Cameron,
> Steve wrote: ]
> > Subject: RE: How well does CVS handle other types of data?
> >
> > On the issue of whether storing binary files in CVS is a go
Just thought I'd mention one problem with trying to store binary
files in CVS that nobody has mentioned yet
It's not too hard to get diff to run out of memory with binary
files, (compared to ascii files.) I have one file in my repository
that I can't commit to because of this. Luckily, it'
R. Bresner wrote:
> We've just installed cvs 1.11 from 1.9 and are noticing a different
> behavior
> with -r HEAD. (client NT, server Solaris).
>
> When diffing a branched area, CVS is getting the head of a branch
> based on the revision of a file. We have many files that are branched,
> but h
Ingolf Steinbach wrote:
> has someone written an awk/perl/whatever script which
> generates a table with (at least) the entries "local
> file name", "revision", "date of checkin" from a static
> tag and a locally checked out copy of a module?
Perhaps you already know about this:
cvs rdif
Nevermind, I already checked the case I was thinking of. From
my patch, (Duh!) (Thanks Derek P. for reminding me.)
+
+ dotest dotorigin41 "${testcvs} rdiff -s -r dot5.origin
-rdot5 mydir2" \
+ "${PROG} [a-z]*: Diffing mydir2
+ File my
Hmm, this might have implcations for my ".origin" patch that I'll have to
look into,
if I didn't already consider it...
http://www.geocities.com/dotslashstar/branch_patch.html
-- steve
Derek R. Price wrote:
[...]
> Hmm. You're right, and the culprit seems to be that 'cvs tag
> tag_
> I have downloaded the latest 1.11 sources and
> compiled them on the AIX box,
[...]
> Can someone either identify what is missing above, or give
> me some ideas on what else to check?
Other idea: AIX by default arrogantly runs writesrv
listening on port 2401, though it sounds like
you alr
Patrick Vicanti wrote:
> [...]. Is there a CVS command, utility or process that can tell me
> what files have changed in the branch vs. which ones have been untouched
and
> are the same as the ones in the trunk? Thanks.
cvs rdiff -s -r tag_on_the_trunk -r tag_on_the_branch modulename
The "-s"
Michael Bailey wrote:
>
> I've been asked to update file versions for all files on a branch to 2.0
> Although I realise this is not the cvs way, would it be A Bad Thing?
>
In short, yes, it's a bad thing in my opinion. it will only cause
confusion without providing any real benefits that are
David Munt wrote:
> I am about to branch from an existing branch. The existing branch
> has tags set up to allow merges to and from the trunk and I have
> successfully merged changes from the trunk into the branch
> several times. The new (sub)branch will, ideally, allow merging to
> and fro
I didn't see anybody else actually provide a way out, other
than to say that /tmp is full, because it's a memfs, and therefore small.
One way out is the "-T" option to cvs, (on the server side) to tell CVS to
use
a different directory then /tmp for this.
See: http://www.cvshome.org/docs/manual/
> $ ls -laR /tmp/cvs-serv13733/
> /tmp/cvs-serv13733/:
> total 5
> drwx-- 4 cvsuser cvsusers 1024 Oct 11 07:31 .
> drwxrwxrwt 6 root root 2048 Oct 11 07:31 ..
> drwxrwxrwx 2 cvsuser cvsusers 1024 Oct 11 07:31 CVS
> drwxrwxrwx 3 cvsuser cvsusers 1024 Oct 11
Derek R. Price wrote:
> The only thing my method shouldn't account for is files removed from the
> branch
> and not the trunk. You should be able to use a diff to get those if you
> need to.
> Try Steve's method first if you have the A tag or can get it into place.
[smc] If you don't h
Logan Wilkins wrote:
> I need some help with a simple problem. I'd like to move a branch
> back to the main trunk, but I don't want to merge the revisions; I
> want to overwrite what's in the main trunk with what's in the branch.
> Does anyone know of a way to do that. Thanks in advance,
Greg Woods wrote:
> $ /sbin/ping -v -D -s 1373 208.184.89.19
> PING apache.openave.net (208.184.89.19): 1373 data bytes ^?
apache.openave.net PING Statistics
> 6 packets transmitted, 0 packets received, 100.0% packet loss
>
>
> $ /sbin/ping -v -s 1373 208.184.89.19
> PING apach
Hmm, just built cvs 1.11 on unixware2.1.2, running pserver,
with unixware 7 and Openserver 5 clients running cvs 1.11
With a 1.10.8 pserver on unixware 2.1.2, the 1.11 clients work
fine, but when I try switching over to a unixware 2.1.2 +
cvs 1.11 pserver, I get (on the client side)
cvs co -
I just duplicated this with cvs 1.11.
cvs update -A
cvs tag sometag
cvs update -r sometag
rm somefile
cvs remove somefile
cvs commit -m removed.
The net effect is that "sometag" gets removed from "somefile"
Is that intentional? Seems like it could be considered a bug to me,
the normal way to
John Carter wrote:
> Alas, this is a bit of a problem. In that there are hundreds of
> the @##$! things. And as I have found out, people tend to get a bit lax
> about booking files in. (I found out the hard way, by moving from RCS to
> CVS and finding nothing worked. People had been too lazy / fo
Noel Yap wrote:
> It's interesting that none of "cvs edit -c", "cvs edit -f", and "cvs ci
-c" made
> it into this release even though the patches have been out there for quite
some
> time (at SourceForge under project RCVS) and many people are already using
it.
> IMO, these patches are extremely
There's a discussion over on Advogato about
version control systems, wishlists for CVS
or other such systems, etc.
that some of you may find interesting.
Apparently Karl Fogel is working with
some other folks on something called
"Subversion"... Anyway,. here' s the URL.
http://www.advogato.or
I wrote:
> Chris Deever wrote:
>
> > Is there a way to check out a branch such that CVS retrieves the branch
> as
> > it was before any new changes were committed to it?
[...]
> I have a patch to CVS that might help do what you want.
>
> It's at http://www.geocities.com/dot
Chris Deever wrote:
> Is there a way to check out a branch such that CVS retrieves the branch as
> it was before any new changes were committed to it? Alternatively, is
there
> a way to determine the date on which a branch was created? I have tags
from
> the same time period that the branch was
matt wrote:
>
>If I do a "cvs checkout -r tagname" and then a "cvs tag -b
>branchname" will this create a branch from the tag?
>
Yes. Also, you can skip the checkout step by using "rtag"
if you have a module defined for what it is that you want to tag.
cvs rtag -b -r tagname branchname modulen
Win32 M$ wrote:
> Dear Laine Stump,
>
>> Oddly, http://www.wincvs.org points people at this mailing list (the CVS
>> mailing list) when they have questions about WinCVS. I'm not sure why
>> they haven't setup their own mailing list, as other frontends, such as
>> tkCVS, have. It would seem to m
Robert Sfeir wrote:
> Toyed around with this thing. Forgot the name of the
> gentleman who tried to help. I added the 10.0.0.172:
> cvspserver to the machine and it doesn't work. So
> here are my questions:
> Can this IP be an aliased IP or does it have to be
> bound to another ethernet card
> > Shawn Anderson writes:
> >... trying to figure out the best way to transport full directory
> > hierarchies into the Attic.
>
> There's a very easy way:
>
> cvs co directory_to_remove
> cvs rm -f directory_to_remove
>
>
>
>
> Shawn Anderson writes:
>... trying to figure out the best way to transport full directory
> hierarchies into the Attic.
There's a very easy way:
cvs co directory_to_remove
cvs rm -f directory_to_remove
Larry Jones wrote:
> Stephen Cameron writes:
>>
>> Is the CVS server at cvs.cyclic.com still accepting
>> anonymous connections? It was a few days ago, I'm sure.
>
> It seems to have quit accepting connections of any kind
> sometime yesterday afternoon. I presume it's being moved
> from So
Veronica Lee wrote:
> Does anyone know by any chance how to get a list of files and their
> paths committed on a certain date? For instance, in the following
> output:
>
> dir_a/file_a
> dir_b/file_b
> dir_c/sub_a/file_aa
How about something like this:
cvs rdiff -s -D 'Jun 29, 2000' -D
[EMAIL PROTECTED] wrote:
> I messed up a merge into a branch and need to roll that entire branch back
to my premerge tag.
>
[...]
I would do it this way:
(Assuming you have a top-level module called "everything"
and a pre merge tag called "pre_merge_tag" and your
branch tag is called "bra
David Thornley wrote:
[...]
> .main.latest
> types easy too. (. is in the central part of the three basic rows
> of the QWERTY keyboard, and doesn't require a shift key.)
".main" is fine by me.
[...Regarding support for redundant ".latest" suffix for branch tags.]
>And similarity with the ma
(I think the subject line no longer applies)
Greg Woods wrote:
> (There could be a bit of a chicken&egg problem to solve for ".base"
> though -- I think you actually have to create it if you want it because
> of the late branching optimisation, which is something you cannot avoid
> if you want
Fabrice Lavier
> This works :
> cvs co -l -rb0808 -D "60 days ago" foo
> % cvs -v
> Concurrent Versions System (CVS) 1.10 `Halibut' (client/server)
[smc] Oh. That was easy. :-)
Hmm. I think I was remembering the code in "rtag.c",
and "tag.c" which forbids the combinatio
I wrote:
> Also, though it might be nice to have a consistent
> vision for where we would like things to go, I don't
> think all these things necessarily need to be done
> at the same time.
Actually the next thing I'd like to see would be the
ability to specify -r branch and -D date option
John Cavanaugh wrote:
> I havent really followed this thread much but when I looked into
> implementing this and reviewed the code. Yikes, the HEAD stuff
> scared the crap out of me in terms of funky things that work and
> dont work.
>
> I applaud the work being done to get us there but I think
Michael Richardson wrote:
> I was reading your patch to try and understand why .trunk is needed...
> "Stephen" == Stephen Cameron [EMAIL PROTECTED] writes:
[..].
Stephen> +
Stephen> + CAUTION: the special tag `HEAD' is interpreted by
Stephen> + the `cvs diff' command in a d
Brian Collins wrote:
> Eric Siegerman wrote:
[...]
>> The Right Thing(TM) would probably be to collapse (ie. "merge and
>> forget") the branch and start a new one, rather than doing
>> multiple merges from the existing one -- but I'm not quite sure
>> how to do this in a context of ongoing bug-f
Greg Woods wrote:
> [ On Monday, June 19, 2000 at 17:12:42 (+0100), Mike Little wrote: ]
> > Subject: RE: ".trunk" patch refinement
> >
> > Would '-r1' work if some previous cvs admin had updated vast numbers of
> the
> > trunk revisions to 3.x (presumably when version 3.0 of the product was
> >
I wrote:
> Greg Woods wrote:
[...]
> OK, so exactly how is this [my .trunk patch] different from "-r1"?
> Seems like it's the
> same thing to me, which means it's an awful waste of coding effort,
> not
> to mention the extra typing necessary to use it... ;-)
Greg Woods wrote:
> [ On Saturday, June 17, 2000 at 21:41:49 (-0700), Stephen Cameron wrote: ]
> > Subject: ".trunk" patch refinement
> >
> > Ok, here's a refinement of my ".trunk' patch that gives
> > the trunk a branch-tag name, just like other branches
> > (from the user's perspective, the impl
I wrote,:
> [smc] A patch that creates a pseudo-branch tag ".trunk"
> >
> > http://www.geocities.com/dotslashstar/branch_patch.html
> > The patch is against the current (6/8/2000) development
> > version of CVS.
[...] I've discovered "cvs log -r .
I wrote:
[smc] A patch that creates a pseudo-branch tag ".trunk"
> >
> > http://www.geocities.com/dotslashstar/branch_patch.html
> > The patch is against the current (6/8/2000) development
> > version of CVS.
> >
>
[smc] I've been playing around with it a bit this morning,
Martin Roehrig writes:
[smc] my words:
> > HEAD as described here definitely has some impossible
> > or at least meaningless cases: for instance, a sticky,
> > non-branch tag (or date or revision) on a file could
> > match a revision that is present on m
Larry Jones writes;
[my words]
> > But, does anyone here know how to
> > implement either HEAD or TRUNK as
> > described here?
[ HEAD meaning the
tip revision of "the current branch", acting like
whatever branch tag[s] are in effect. TRUNK
ac
> Martin Roehrig writes:
>
[...]
> > HEAD should then always refer to the latest revision in the branch resp
> main
> > trunk the current working copy is based on and therefore it should not
> be allowed
> > in cvs commands that directly work on the repository (like rdiff - don't
> know
Martin Roehrig wrote:
> Larry Jones schrieb:
> > Peter Wolfe writes [about HEAD meaning the head of the current branch
> > rather than the HEAD of the trunk for diff]:
> > >
> > > Hmm ... while that might be the design intent my observations are that
> even
> > > this is broken:
> >
> >
Peter Wolfe wrote:
[...]
> Hmm ... while that might be the design intent my observations are that
> even
> this is broken:
>
[smc] [ by "this", the behaviour of "cvs diff -r HEAD" is what is
meant. ]
> pw.notus.1783> cvs -n update
> ? .d
[bunch of ? files deleted ]
>
Deever, Chris C. wrote:
> When comparing a branch agaist the base trunk, I've noticed a scenario
> where
> WinCVS 1.1b13 (client) and CVS 1.10.6 (server) miss some of the
> differences
> in the base trunk. In all developement branches, all changes are
> comitted.
>
> When I go to the root dire
Noel Yap wrote:
> And how about adding (different levels of) security to such a setup?
>
[smc] For one, a discussion of setting up secure anonymous
read-only
access would be cool. (I don't think this is thoroughly documented
anyplace,) and how to set up cvsweb, that mig
[smc] Derek Scherger wrote:
[...]
> $ cvs update
> cvs update: Updating
> U file1
>
> $ mv file1.old file1
>
> After which cvs status knows about file1 and considers it modified or up
> to date depending on what was there in the first place.
>
> What about providing an option t
Larry Jones wrote:
> Since the current repository is still active, you need to handle this
> very carefully to ensure that changes don't get lost in the process.
> Best would be to get the actual machine containing the repository from
> SourceGear (which is what they did when they bought
Larry Jones wrote a brilliant analysis of my flawed algorithm.;
[]
> No, I mean that the mapping between UTC and local time is very
> complicated [...] What you
> want is to have the results switch back and forth between standard time
> and DST as appropriate.
[smc] oh yeah, ha
At Larry's suggestion, I'm moving this over to info-cvs, from bug-cvs.
Larry Jones wrote:
> -Original Message-
> From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, May 19, 2000 2:02 PM
> To: Cameron, Steve
> Cc: [EMAIL PROTECTED]
> Subject
[smc] Andy Glew wrote:
>
> However, I agree with Noel about minimizing sysadmin involvement.
> Sysadmin should only be required to set up user accounts.
> The setup of the CVS project, repository, management of permissions,
> etc., none of it should require sysadmin involvement.
> Thi
> I'm getting some weird results from 'cvs rdiff'
>
> scameron@zuul 1097 $ cvs rdiff -s -r 0.0 -r efs_x36_dev_br abd
> cvs server: duplicate key found for `y'
> cvs server: Diffing efs/unix/autobuild/abd
> File efs/unix/autobuild/abd/Changelog.x30 is new; current revision 1.2
>
> What's the "d
> Steve Cowling wrote:
>
> The following error was scrolled down the screen:
> bread in fat_access not found
> We are running Redhat version 6 on a PC and it has been running fine
> for about 6 months. The latest work done has been to start using CVS
> which was installed with the initial
Larry Jones wrote:
[...] : rebuilding the modules database *does* explicitly
> check for duplicate keys. So, the problem isn't with the modules file
> after all, it's with CVSROOT/val-tags (which I had completely forgotten
> about). [...] You can just delete any lines that don't look rig
No, that will not work. In fact this will leave you with no branch tag at
all
since you didn't use "tag -b", and actually in a very bad place, with no
way to recover the lost branch tag.
Actually, within the confines of CVS, I do not think there is a way to
rename
a branch tag. (If I'm wrong,
[smc] David Thornley wrote: [...]
> If xmalloc is to initialize memory, I'd prefer it to be initialized
> to something obviously bad. Jonathan Gilligan had some very good
> suggestions. Now, "obviously bad" is system-specific, but it's better
> than initializing to a value selected to
Larry Jones wrote:
> -Original Message-
[smc] [...]
> > 4) Automatic NTP correction of the system time (pretty common in the
> Unix
> > server world).
> > (Under Windows 2000 it is possible for all the machines in a given
> > domain to periodically
> > sync their clocks
Larry Jones writes:
> I'm behind a firewall, too, but the point of a firewall is to keep bad
> things from happening, not to keep good things from happening. If you
> can't get some route through the firewall when you need it, then you
> have bigger problems than keeping up-to-date with the CVS
Robert Clavelle wrote:
"Tell me more about CVS" (along with a
relatively massive signature)
More than what? More than you ever wanted
to know? Try http://www.cvs.com (Heh heh. :
Ask a silly question... :)
You might try these after you're tired of that one.
http://www.cyclic.com and
http:
Oops, I wrote:
> Michael Gersten wrote
> [...]
> > Just a thought, what's wrong with
> >
> > cvs rtag -r oldtagname newtagname
> >
> > to rename a regular tag?
> [smc] Well, this is already valid syntax, in which "newtagname" is
> interpreted as a module name.
Michael Gersten wrote
[...]
> Just a thought, what's wrong with
>
> cvs rtag -r oldtagname newtagname
>
> to rename a regular tag?
[smc] Well, this is already valid syntax, in which "newtagname" is
interpreted as a module name.
[EMAIL PROTECTED] wrote:
> Greetings!
>
> Our developers will tag their code for builds under test, and when
> problems
> are fixed, they will move the current tag until the product is shipped and
>
> the tag is frozen. Occasionally, someone makes the mistake of moving the
> branch tag inst
Greg Woods wrote:
[...]
> It makes me wonder though if a magic pseudo-tag could even be
> implemented right in the case of bumped release numbers without jumping
> through a whole lot of hoops. I can't at the moment think of a way to
> inidicate to RCS that the top of the trunk should be
Greg Woods, CVS guru, wrote:
[...]
> > If somebody is interested, I can try to make a version of my patch
> that
> > makes HEAD work as it does for "cvs diff" in all the other cases. I
> don't
> > think it's very hard. (Hardest part will probably be fixing
> sanity.sh...)
Greg Woods wrote:
[smc] [...]
> >
> > My view of it was that currently HEAD appears to mean the head
> > of the trunk, with the one exception being that "cvs diff" treats it
> > differently. So my reasoning was to "fix" that one excetption, is
> all.
>
> The question is h
Greg woods wrote:
[...]
> My preference would be to do what is effectively the opposite of what
> Steve Cameron's proposed patch does.
>
> I.e make "HEAD" always refer to the head of the current branch
> (or the trunk if there is no sticky branch in effect; or if no branch
> name is gi
[...]
> > Yes, CVS doesn't record a new version [on a new branch] if you don't
[ commit any change] . That's annoying. [...]
> Well, you can determine full branching order for any branch creations the
> file
> was included in, due to the tags, so I'm not quite sure why not cre
Michael Gersten
> > You're right. For consistency's sake, "cvs up -C file" should get a
> clean copy
> > of the HEAD. I think, in general, there should be a way to specify the
> base
> > revision (is there a BASE alias similar to HEAD?)
>
> Ok, since HEAD means different things, etc, I'd like
Noel Yap wrote:
[smc] [...]
> >I think (maybe) you just want
> >to use "RCS_branch_head()" instead
> >of "RCS_head()" in the code for "cvs up -C" similar
> >to what "cvs diff" does in the HEAD case.
>
> Yes, you're right. I wasn't really aware of this meaning of HEAD s
Noel Yap wrote:
[smc] [...]
> >
> >Are you sure about ''? From what I've seen so far, -C means
> 'clean
> >copy'. (it's not on my 1.10.5 copy, gotta upgrade).
> >
> >By '', do you mean the revision last checked out, or the
> current
> >revision for the current sticky tag?
>
> You're r
Dave Makower wrote:
> This information is documented, but I want to make sure I am correct
> in my understanding of it.
>
> Is it true that when used with the -r option, 'HEAD' always refers to
> the latest revision on the _main_ _trunk_, or does it refer to the
> latest revision of the file,
[EMAIL PROTECTED] wrote:
> My curiosity is piqued by several posts recently on the subject of
> builds.
[smc] [...]
> For those of you that do run builds of your products/systems where cvs
> is the underlying version control system, how many of you:
>
> 1. Run them (let's say nightly
You only need to "cvs login" one time. After that it is not necessary,
The information is stored in ~/.cvspass
If your cron job is using different CVSROOT values for each
time it is run (seems unlikely) then you'd have to log in
of the CVSROOT values once. (presumably there is a
small, finite
> Is there a clean way to merge from a branch in such a way that the
> resulting
> merged file is exactly the same file that was on top of the branch when
> the
> merge command is issued ?
[smc] You mean copy the files on the branch onto the trunk,
throwing
away any changes made
Laird Nelson wrote:
> Can someone give me a pointer on when to use cvs tag vs. when to use cvs
> rtag? I know, for example, that cvs tag doesn't show up in the history
> file, and that cvs rtag requires you? I think? to feed it the revision
> number of whatever you're tagging, thus preventing yo
Eric Hernandez wrote
> Hello,
>
> I have a repository set up as: /xxx/src/master
> The contents look like this (using 'ls'): CVSROOT Scripts ccvs
> As user Joeshmoe, I execute the command 'cvs checkout ccvs' which
> results in
> cvs checkout:Updating ccvs
> U file1
> U file2
[s
[smc] [snip]
[smc] [..regarding "cvs update -j rev1 -j rev2 myfile.c" ]
> >
> > rev1 and rev2 can be arbitrary revisions. (Well, with the
> > restriction
> > that they must already be in the same repository...which is
> > the main difference I see fro
I wrote:
> That list ("devel-cvs") already exists, sort of.
>
> Read the file DEVEL-CVS from the cvs sources.
[smc] And reading this DEVEL-CVS file a bit myself,
now I see this:
"These topics should either go on info-cvs,
or have a new mailing list created for
That list ("devel-cvs") already exists, sort of.
Read the file DEVEL-CVS from the cvs sources.
(it mentions "[EMAIL PROTECTED]"...I don't know
if that still works...)
Essentially anyone may read the messages sent to
devel-cvs but only those who are able to
commit to the CVS repository contain
Tobias Weingartner wrote:
> On Tuesday, March 7, Michael Gersten wrote:
[smc] [..snip..]
> > The current CVS update/commit, without built-in support for flying fish,
> > does not support that middle step: track changes to it.
>
> Ahh, I think you need to look into tags. One place I w
Bergur Ragnarsson writes:
(and I'm moving this thread over to info-cvs rather than bug-cvs, because it
seems
more appropriate, to me.)
> Hello all,
>
> I'm using CVS 1.10 and I am quite happy with it; however there is one
> very important feature missing:
> CVS rename
[smc] [...s
Noel yap wrote:
> "cvs up -C file" doesn't work correctly if "file" has been modified both
> in the
> repo and the working directory (ie a merge is "needed"). IMO, you should
> wind
> up with a clean repo copy (ie no merge). The default repo copy should be
> the
> HEAD
[smc] or the tip
Art Solano wrote:
> Can you script cvs login? I have read through the documentation and it
> only seems to be interactive.
>
[smc] It is AFAIK, always interactive, like telnet. That doesn't mean it
can't be scripted, what you might want is "expect", a program made
specifically for dealing w
Noel Yap wrote, (about his "edit -c" patch
[...]
> I think it might require server connection when using "cvs edit",
> but I haven't tested this (ideally it should only emit a warning but I
> haven't
> taken the time to find out how to do this (ie test whether or not the
> server can
>
> -Original Message-
> From: Thomas Wichmann [SMTP:[EMAIL PROTECTED]]
> Sent: Sunday, February 27, 2000 5:50 PM
> To: [EMAIL PROTECTED]
> Subject: CVS server problem on Solaris
>
>
> Moin, moin
>
> I have a strange problem with "CVS 1.10 `Halibut' (client/server)".
> It is a n
> Cameron, Steve writes:
> >
> > So maybe it will work after all, if you run CVS as root.
> > (though this surely defeat any security gained by
> > keeping passwds in /etc/security/passwd)
>
> I'm not sure what you mean by that. The idea of shadow pa
Noel Yap wrote:
[...]
> If you do come up with a general solution, here's my wishlist:
> 1. The global .cvsrc is copied onto the client (assuming client/server CVS
> of
> course) so that server contact isn't mandated.
> 2. By default, user .cvsrc files extend global .cvsrc settings.
> 3
It looks like getspnam doesn't exist, but getpwnam()
does on aix, and further, according to the man page,
getpwnam will look in /etc/security/passwd if the
process has privilege to do so.. (is running as root)...
So maybe it will work after all, if you run CVS as root.
(though this surely de
David Martin wrote:
> Sankaranarayanan K V wrote:
>
> > I am trying to make the HEAD of a branch B1 the same as that of another
> > branch B2 by:
> >
> > cd
> > cvs update -j B1 -j B2
>
[smc] [...doubts about CVS supporting arbitrary merges snipped...]
>
> I would think
Sankaranarayanan K V wrote:
> I am using CVS 1.10.7 on Solaris 2.5.1.
>
> I am trying to make the HEAD of a branch B1 the same as that of another
> branch B2 by:
>
> cd
> cvs update -j B1 -j B2
>
> This should NOT give me any conflicts.
>
> But I do get conflicts in some cases -- I don't
One solution is this:
on AIX look in /etc/services, it has "writesrv" running on port 2401
This is apparently how IBM decided to implement the "write" command
which allows users to "write" messages to each other's ttys. Probably
nobody uses this command at your site, since pretty much nobody
us
Noel Yap wrote:
> Beware of premature optimisation. We've already laid out a process that
> relies
> on empty directories being created in the repo. IOW, it's *necessary* to
> allow
> creation of empty directories for this process. It would be a kludge to
> create
> a dummy file for this purpo
Sankaranarayanan K V wrote:
> On Thu, Feb 17, 2000 at 09:33:03AM -0600, Cameron, Steve wrote:
>
> > for "cvs diff", HEAD means the head revision of the branch
> > sticky tag.
> >
> > for all other commands, as far as I can tell, it means the head
Little Green Men ( [EMAIL PROTECTED] ) wrote:
> Hello,
> I have a little concept question.
> what should be the correct way of setting an cvs environment for several
> developers ?
[smc] How many is several? I will assume < 10.
> should we open a separate branch for each developer ?
Sankaranarayanan K V wrote:
> Hi,
>
> (1) How do I refer to the trunk in commands like
>
> cvs update -j
>
> cvs diff -r
>
> where branch can be either a proper branch or the trunk itself.
>
> (2) What exactly does HEAD mean?
> Is it the head revision of the trunk or of the sand
1 - 100 of 104 matches
Mail list logo
