"command=" option
doesn't suffer similar weaknesses.
- Frodo, having lost a finger to his famous adventure with a
magic ring, will want nothing whatsoever to do with your
$@*!# magic key :-)
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.
impossible password.
>
Which is why this is safe.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
to me, Charlie Brown represented the courage to be sincere in the face of
ridicule. he was NOT a loser.
thank you, Mr. Schulz.
- Robert C. Mayo
would consume all the input,
and the second wouldn't see any. The only way I can think of
to do this is to save the list in an intermediate buffer.
Fortunately, this particular case is easier:
find . -type f -print | grep -v CVS | xargs cvs rm -f
(No quotes, by the way.)
--
|
r-x 4 ericswww 512 Jun 14 18:04 ..
drwxr-xr-x 2 ericswww 512 Jun 14 18:04 CVS
$ cvs tag -b branch
cvs tag: Tagging .
$ echo $?
0
$
It would suffice if this also added "branch" to val-tags.
--
| | /\
|-_|/ >
se ... but each is wrong for the other
team's development style. Not too surprising; each company will
have picked a tool that suited their way of working, or adapted
to the tool's way of working, or most likely some of each.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont
add file `index.htm' when RCS file
>`/export/home/cvs/netops/doc/index.htm,v' already exists
> cvs [server aborted]: correct above errors first!
>
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
[Microsoft's] www.hotmail.com
ot;say -r1 when you mean latest-on-trunk" is a kludge, to work
around the lack of ".trunk". That it fails on trunk revision 2.x
isn't a corner case in CVS; it's a limitation of the kludge.
The man's offering to obviate this kludge with a correct
solution; what
ne -- but I'm not quite sure
how to do this in a context of ongoing bug-fixes to the previous
release.
The expedient thing, if the "Line 2 on the trunk" changes are
fairly localized, might be to check them in on the branch, so
that there's no longer a disagreement.
On Tue, Jun 20, 2000 at 05:07:04PM -0700, Zieroth, Brian D. wrote:
> I'm getting a problem (see below) whenver I try to a "get".
The operative line is "Permission denied". You can't write to
/cvs/sql/data_model.
--
| | /\
|-_|/ > Eric Siegerman, T
logs, temp files,
or other things that are not intended to be CVS-tracked, you'll
need a .cvsignore anyway. Since that will suffice to make the
directory non-empty, you won't need a .keep_me file as well.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|
#x27;s assumptions and the client O/S's file-copy
semantics, not to any mis?-configuration of CVS. Therefore:
> This, really, isn't a problem of CVS!
I beg to disagree. I've even been bitten by this once or twice
even in a pure-UNIX context (I can't remember the de
all, which is the salient detail
here.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
[Microsoft's] www.hotmail.com is running Apache/1.3.6 (Unix) ... on FreeBSD
- Netcraft's "What's that site running?" service, 12-Jun-2000
se it. If
you *redistribute* it, you still don't need approval, but you
need to do certain things (like make the source available).
Long answer: read the GPL. It's not that painful. Really. It's
the COPYING file in the CVS distribution, or
http://www.fsf.org/copyleft/gpl.html
he API provides no way to specify the mapping).
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
[Microsoft's] www.hotmail.com is running Apache/1.3.6 (Unix) ... on FreeBSD
- Netcraft's "What's that site running?" service, 12-Jun-2000
directory names based on the
> original cvs invocation pid.
Why not make the original cvs (pid 1000 in my example) export the
temp-dir name into an environment variable? The variable would
be scoped correctly, by definition. And there would be no
reliance on PIDs.
--
| | /\
|-_|/ > Eric
has long claimed to differentiate.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
[Microsoft's] www.hotmail.com is running Apache/1.3.6 (Unix) ... on FreeBSD
- Netcraft's "What's that site running?" service, 12-Jun-2000
ity fixes only. Developers on the head
> branch should feel free to make radical changes.
and as other open-source projects have already discovered.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
[Microsoft's] www.hotmail.com is running Apache/1.3.6 (Unix) ... on FreeBSD
- Netcraft's "What's that site running?" service, 12-Jun-2000
On Thu, Aug 03, 2000 at 04:09:56PM -0400, Laird Nelson wrote:
> - Original Message -
> From: Eric Siegerman <[EMAIL PROTECTED]>
> > Why not make the original cvs (pid 1000 in my example) export the
> > temp-dir name into an environment variable?
>
> I'd
you checkout
> everything into.
>
> Then from your home directory create symlinks into the subdirectory.
I've done this. It works great ... and has the fringe benefit that
I can tar up the subdirectory to get it to machines that can't reach
my CVS server (or that don't (yet)
was going on.
Or maybe something just went bad in the running kernel, and the
reboot's all that was needed. But I'd want to put a fair amount
of effort into convincing myself that's all it was.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| |
ot;module revision" is
appropriate at the moment. And they have to remember the "-r" at
commit time, which may be quite a while after they "cvs add"ed
the file. It's easy to forget to do this; thus, any process that
depends on it is bound to be fragile.
Use CVS tag
re quality. And
I'm afraid of pointy-haired managers who'll take the latest fad
in programming metrics as gospel, and use them as a cheap and
easy substitute for doing their own jobs properly.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, On
dn't know). Search the
list archives for references.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)
__
commit.
The former would preserve consistency with current behaviour; the
latter would bring this case more into line with the rest of CVS.
Which of these would be preferable?
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fl
RCS 5.7 can handle files with custom metadata,
> but it prints a warning. So even if CVS does extend the format
> in this way, that won't prevent people from using RCS to get at
> the data in an emergency.)
>
> If CVS opts for adding "newphrase"s, enhancing binary-file
So you want to
merge that bug fix only, but keep the rest of the fixes on B
isolated until a later date.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
-
'll start with a clean slate but then bring a significant
amount of stuff over from the old implementation, that's a hard
one. I'd lean towards (4) ... but then, I'm a bit of a purist.
I'd be interested to hear others' opinions too.
--
| | /\
|-_|/ > Eric Sie
his is
how you'll be able to get back the exact sources that went into
the release -- a branch tag won't be as helpful there.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this
n the RCS files because the RCS file
format is extensible.
It *should* be stored there because it's a permanent part of the
file's history, not transitory like edit/watch info, and so
belongs with the rest of that history.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.
sing diff and patch?
Or merge, from the RCS distribution. That's the very small part
of CVS that does the actual work of merging files. What the rest
of CVS contributes is figuring out *which* files to merge :-) --
a problem you don't seem to have.
--
| | /\
|-_|/ > Eric Siege
e allowed to run on that particular box is "cvs". You
might even be able to restrict it to "cvs server", but I'm not
sure about that.
If they still insist, even with a WWW interface, then NFS-mount
the repo read-only on the machines they use. That way, at least
they can
On Thu, Jun 21, 2001 at 01:57:32PM -0400, Matthew Riechers wrote:
> Eric Siegerman wrote:
> >
> > I don't
> > recall how, but you can set SSH up so that the *only* command
> > they're allowed to run on that particular box is "cvs".
>
> You c
overing easier -- with CVS, it's just a standard
merge).
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)
ement something like this for
CVS (for Linux clients anyway). Someone responded by mentioning
Katie, another system based on this idea (not CVS compatible,
afaik). Neither is ready for prime time, but stand by.
http://sourceforge.net/projects/cvsfs/
http://www.netcraft.com.au/geoffrey/katie/
--
too large
> for defined data type
Maybe the CVS RPM is out of sync with the kernel. Try compiling
CVS from source.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good ide
exists* says that there was enough demand for it for M$ to
devote resources to that rather than some other feature. Which
in turn argues that the concepts aren't inherently beyond (all)
non-techies, as long as they're presented in a form they can
understand (which Word does pretty much
> Needless to say I'm moving soon to a client/server model to avoid
> this and similar issues.
Good plan :-)
> btw, the utility i need this for is a small vb thing which parses the output
> from cvs log into [a condensed version]:
> [...] if this already existed and I re
ings this way if at all possible.
Same goes for remote-mounting your CVS working directory, or the
repository.
Use CVS client/server, with a client that's native to your
machine.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pig
version of CVS?
> Does anyone
> know if I can revert this change and fix this?
How can we, until we understand the problem?
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good i
ime, CVS is able
to completely ignore the files in the Attic directories, so that
they don't add any performance penalty. It can't *always* ignore
them, but the times when it must look at them are precisely those
times that you'll regret it if you moved them someplace else.
--
| | /
ore problems, including the never-ending headache of
botched line endings.
Use CVS client/server instead.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
"Doctor, it hurts when I do this."
"So don't do it."
__
atest branched version, do I need to simply
> > check out -r branch_tag_text???
>
> Correct.
Because "cvs {co|update} -r branch_tag_text" explicitly says: for
each file, give me that file's latest revision on branch
"branch_tag_text", whatever its revision numb
ke the
> plague.
I thoroughly agree about $Log$, but:
- what's evil about the rest?
- why do you put $Header$ in the "totally evil" class, not
merely evil?
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pi
If you move your repo all that info becomes wrong even though
> nothing else has to break.
Point taken.
> Well over a decade ago I argued for [...]
> a way to expand just the relative path-prefix within
> the repository
Now that you mention it, I seem to recall wishing for the same
t
eved.
"cvs log" is indeed what you're looking for. If it's not showing
any commit messages, it's because there aren't any :-(
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, thi
ut in the
non-sticky case, my mistake will pollute the repo; in the sticky
case, I'm the only one who'll suffer.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good
On Wed, Jul 11, 2001 at 11:33:48AM -0700, Ketan Shah wrote:
> I would like to collapse this branch and have these files on the main
> trunk.
Use the -j option to "cvs update". See the manual for details.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROT
On Mon, Jul 09, 2001 at 04:12:30AM -0400, Greg A. Woods wrote:
> [ On Monday, July 9, 2001 at 00:01:01 (-0400), Eric Siegerman wrote: ]
> Well, with CVS the meaning of "frozen" file is quite a bit different.
>
> In the most basic sense what I'm saying is that "
discussion on the topic)
- I don't think it ever preserved setuid or setgid (at least,
an old version of the manual doesn't list those as among
the attributes it preserved)
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient
TAG happens to be a branch tag, but is (usually) just annoying
when TAG happens to be a release tag.
When I referred to "sticky non-branch tags", that was shorthand
for "the sticky behaviour of 'cvs update -rNON-BRANCH-TAG'".
That's a common idiom on this list (and
", the implication being that the former should
be revision-controlled and the latter typically not, then there's
NO difference between source whose form is text and source whose
form is binary.
If people were careful to say "object" when they meant
"machine-generated
. I'm not
sure why. (Exception: the vendor branch is 1.1.1 by default.)
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925
the problem of someone going "cvs admin -kkv ." and recursively
clobbering any binary-file settings in their project.
To my mind, protecting "cvs admin -k" is a much more compelling
reason to add the -kf mechanism than allowing people to forcibly
override -kb at checkout time.
--
lost in the
haystack.)
Are there other problems besides these two?
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
ge it into your mainline. It
won't bother CVS that there were two imports with no intervening
merge; it'll just take the latest and greatest from the vendor
branch, and not even notice the preceding junk revision.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[
> anybody cares.
If they're compelling reasons not to do as I've suggested, an
explanation might help us to come up with a (perhaps still
nonstandard, but less ugly) way to do what you need.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAI
;s probably OK.
But then, why expend all this extra effort to do something
counter to CVS's documented design, just because you ought to be
able to get away with it? The conversion script already makes
sure the branch numbers are even; why not just go with the flow?
--
| | /\
|-_|/ > Er
of course, but in fact it
won't work at all.
For how to do it in this less-than-ideal world, see the "Moving
directories" node in the manual.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient
er, and each server has to serve correspondingly fewer updates.
One downside to this scheme is that every time a CVS operation
touches a new repo, the user will have to type their passphrase
again. That's annoying enough when there's only one repo! But
if you choose SSH as your connection
in the delay.
(I don't know Exim, so I've assumed a normal client/server
interaction; it's possible that the details are somewhat
different than I've described, but the basic
foreground/background distinction should still apply.)
--
| | /\
|-_|/ > Eric Siegerman, Toronto,
at could well free up the money to invalidate the final
assumption (taken from your first message): "bitkeeper is not
(yet) an option for us" :-)
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The world has been attacked. The world must respond .
Unix-like environment
within Windows.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)
___
Info-
t yourself.
Another possibility in your case is to try WinCVS instead of
jCVS, for this one operation even if you don't switch to it
permanently. It's not a reimplementation as jCVS is; it's a GUI
layer built on the original command-line CVS. The latest WinCVS
version, 1.2, is
.html
They both say pretty much the same thing relevent to your
question, in the process of talking about other things. I
mention them both because one may make more sense to you than the
other.
The rest of both those threads might also be of some use.
--
| | /\
|-_|/ > Eric Sieg
(There may in fact be valid arguments to that effect,
but these aren't among them.)
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
-
hin *one* repository, so why not use that and save
yourself a lot of grief? I refer to branches of course.
http://www.cvshome.org/docs/manual/cvs_5.html#SEC54
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just f
complain that no merge is possible and do nothing
As a workaround, when you get a conflict, you can duplicate these
alternatives by:
$ rm scrambled-file
$ cvs update scrambled-file
or:
$ mv .#scrambled-file.1.X scrambled-file
respectively.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.
nches (*note Reverting
> local changes::).
Perhaps that should be strengthened to "...only one reason...".
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However,
remote-mounting them in the first place is even more
dangerous in and of itself.
> (--- caer baedwin ---)
Wuzzat?
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
With su
. (And by having the log present in the files, there
will be a lot of temptation to go back and fix old messages.)
Much better to leave the $Log$ out and use "cvs log" to browse
the commit messsages.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
s not the full manual, just a quickie tutorial. It assumes
that you want to join an existing project, not create a brand-new
one from scratch. You can't do the latter with either "cvs
checkout" or "cvs add" (although a rather ugly combination of
them can admittedly be used -
knowing
> what the offset is *right now* doesn't tell you anything about what the
> offset was some time in the past.
I thought localtime(3) took care of all that. Or isn't it
portable enough?
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| |
es
containing the requested tag -- obviously a non-starter). But
val-tags is not always correct; tags that are supposed to be
listed in it aren't always there.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The world has been attacked. The world must r
e interested in.
Make that "cvs -n update", if you don't want to actually update
the sandbox.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The world has been attacked. The world must respond ... [but] we must
be guided by a commitment to d
and you're still getting more output than
you think you should be, please go into more detail. "cvs -nq
update" should do what you want; if it doesn't appear to,
something's wrong.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The w
tuation.
The alternative to all of this is to manually "cvs rm" the
obsolete files. (That used to be standard procedure in importing
a new version of third-party sources, before the
deleted-file-detection code appeared.)
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PRO
tainers if you want to do something
> productive about it.
is horsefeathers.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The world has been attacked. The world must respond ... [but] we must
be guided by a commitment to do what works in the long run,
patch
with test cases and all if you only need it once...
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The world has been attacked. The world must respond ... [but] we must
be guided by a commitment to do what works in the long run, not by what
makes us fe
it was posted in June.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The world has been attacked. The world must respond ... [but] we must
be guided by a commitment to do what works in the long run, not by what
makes us feel better in the short ru
prevent me from stomping them with a bit of work ("cvs up -f1.5
-j1.4 foo.c" or "cvs up foo.c; mv foo.bak foo.c").
For many purposes, weak protection might be good enough to
protect against unwanted actions by your authorized users, in
conjunction with strong security t
I can't
remember the details.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The world has been attacked. The world must respond ... [but] we must
be guided by a commitment to do what works in the long run, not by what
makes us feel better in the short
to set g+s on subdirectories
-- but not on files -- so that this propagation will recursively
happen to sub-subdirectories). BSD systems typically propagate
group membership this way all the time; you can't turn it off, so
you don't need to worry about turning it on :-)
--
| | /\
|-_|/
likes to have strict locking turned *on* -- at least, that's
how many of my CVS-created ,v files are set.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The world has been attacked. The world must respond ... [but] we must
be guided by a commitment to d
-d option to ci.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The world has been attacked. The world must respond ... [but] we must
be guided by a commitment to do what works in the long run, not by what
makes us feel better in the short run.
- Je
red sandboxes -- that the sharers can
stomp each others' changes -- doesn't apply. As a side effect,
the paired-programming discipline imposes a (people-level)
locking scheme on the members of the pair, which prevents
concurrent writes. So the prohibition becomes: don't share
ies into this folder.
> What I want is to be able to checkout the dir1 and dir2
> directories directly into c:\test. Is this possible?
Try omitting the "-N" option. I'm not quite sure, but I think
that'll do it.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.
On Sat, Nov 10, 2001 at 05:34:58AM -0800, Terrence Brannon wrote:
> I added some things via cvs add but did not mean to
> add them all. I want to remove some from the schedule for addition upon
> commit.
Just delete the file(s) from your sandbox and "cvs rm" them.
--
| |
re the "diff" is performed to
figure out that nothing in fact changed.
Another possibility is that something's messing with the
timestamps of the files in your sandbox. For example, people
have recently been talking about a problem where WinCVS on
Windows got confused by the day
VS does them client/server is to make a temporary copy
of (the relevent parts of) the sandbox in /tmp on the server, and
then perform the operation locally on that copy.
I'd guess that the file system that's filling up is /tmp, NOT the
one containing the repo.
--
| | /\
|-_|/ > E
_
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/info-cvs
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The world has been attacked. The world must respond ... [but] we must
be guided by a commitment t
not necessary in order to explain what
you're seeing. Once you fix whichever of (1) or (2) is wrong, if
Eclipse *still* doesn't want to check out the file, then you can
start to suspect bugs there.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
except possibly for what "update" prints. Seems to me
I tried it both ways, and "log" just insisted on aborting when it
tried to recurse into the sandbox subdirectory, complaining about
the missing /CVS.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTE
ate -j1.15 -j1.14 ILifecycle.java# See below
cvs commit
For the second update, the -j values should be the "dead" revision you
just created and its *predecessor*, respectively.
Good luck.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|
revisions to
the old repo, too late for them to be copied to the new repo.
(For a large repo, step (1) could take a long time, so this isn't
a purely theoretical concern.)
It'd be much safer to take the repo offline during this process
-- scheduled downtime is almost certainly cheaper
; For the record, CVS gave me a number of
>
> cvs commit: Examining src/whatever
>
> messages, but no indication that it actually did anything (sigh).
That should have worked. I'm not sure why it didn't. If the
files in "changed" all have *exactly* th
g on the branch, so that
when someone goes "cvs update -rbranch", they get nothing?
That wouldn't *prevent* someone from committing to the branch,
but it'd give them a pretty strong hint that doing so isn't what
they really want...
--
| | /\
|-_|/ > Eric S
along with patches I think.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The world has been attacked. The world must respond ... [but] we must
be guided by a commitment to do what works in the long run, not by what
makes us feel better in the short
ly this is error-prone, but it's probably the standard
approach in pure graphics shops, if they can't completely avoid
lossy compression in the first place.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The world has been attacked. The world must resp
in(), and that has no idea who the client's
logged in as -- "root" is the only info available.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
The world has been attacked. The world must respond ... [but] we must
be guided by a commitment t
inadvertent errors. Steve could switch DEV to the trunk and
(what he calls) HEAD off of it, and his "habitual update includes
-A" users would soon learn the error of their ways, i.e. when
their commits kept failing, and they wouldn't be doing damage in
the meantime.
--
| | /\
|-_|/ &
1 - 100 of 523 matches
Mail list logo