Admin -m1.2:All your base are belong to us. Oops.java
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of S I
Sent: Tuesday, June 28, 2005 10:37 AM
To: info-cvs@gnu.org
Subject: Modifying the comment
Hi
Let's say you checked in a file: C:\cvs ci -m wrong
Generally:
cvs admin -mrevision:message file(s)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of S I
Sent: Tuesday, June 28, 2005 10:37 AM
To: info-cvs@gnu.org
Subject: Modifying the comment
Hi
Let's say you checked in a file: C:\cvs ci -m wrong
IMO, the revision of a word document or any other document can and
should be maintained independent of the version control system revision
numbering scheme. Keyword expansion in binaries has the potential to
corrupt so it's not really an option anyway, not even with PVCS.
-Original
It is not possible to remove a directory using CVS. Instead remove the contents
and use the prune option when checking out or updating. To keep a directory
with the prune option use a dummy file such as .empty.
It is not possible to rename a directory but you can remove the old directory
and
Thing is, if this is that frequent there ottabee many reports of stray
locks. I can say we are not seeing that at all but will admit it used to
show up with a product called SmartCVS - not pointing the finger at that
product, just conveying our experience.
-Original Message-
From: [EMAIL
at all hours of the day and night and never get
that lock thingy.
-Original Message-
From: S I [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 22, 2005 2:27 PM
To: Rod Macpherson; info-cvs@gnu.org
Subject: RE: CVS Lock Files
Thank you. But do you see anything wrong with me manually
Why doesn't CVS treat HEAD like a branch tag where the branch is the
main branch, that is to say the trunk. I cannot commit files checked out
as HEAD. Treats it like a garden variety version label versus trunk.
___
Info-cvs mailing list
: Larry Jones [mailto:[EMAIL PROTECTED]
Sent: Tue 6/21/2005 12:35 PM
To: Rod Macpherson
Cc: info-cvs@gnu.org
Subject: Re: HEAD versus Trunk
Rod Macpherson writes:
Why doesn't CVS treat HEAD like a branch tag where the branch is the
main branch, that is to say the trunk.
Why aren't rocks soft
Probably 99% of the how do I lock questions are CVS noobs
uncomfortable with the general answer: you don't.
Bottom line: locking introduces development bottlenecks with almost no
benefit. In fact it's a false sense of coordination where changes are
blown away on a regular basis: bugs magically
The key is that update does a merge from the repository to your local
system. Merge either quietly succeeds or a conflict is detected: first
resolve conflicts, build, test and then check in.
Perhaps you have used systems that lock. They have the same problem with
the added bonus of introducing
CVS automation kicked in for you. It recognized a concurrent change and
instructed you to update your local copy before checking in the changes.
Updating before checking in is a sound policy that avoids those errors.
Allows you to do a local integration test prior to checking in.
You just had a
The silence is telling: not a common problem. As you indicated the
problem is intermittent and not easily reproduced: the worst kind!
Could it be a buggy release? Maybe:
http://lists.gnu.org/archive/html/info-cvs/2004-10/msg00252.html
It is fixed in cvs 1.11.17.1 (will be in cvs 1.11.18) with
-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Neil Watson
Sent: Wednesday, June 15, 2005 11:41 AM
To: info-cvs@gnu.org
Subject: Re: cannot checkout new tag
On Wed, Jun 15, 2005 at 10:59:57AM -0700, Rod Macpherson wrote:
Could it be a buggy release? Maybe:
http://lists.gnu.org
I checked out a sandbox, removed some files then changed my mind. I
deleted the sandbox from my file system and did another fresh checkout
to undo that remove. There was no commit but there was no re-add either.
Remove says it schedules removal so does that mean the repository
still thinks there
Thanks!
-Original Message-
From: Mark E. Hamilton [mailto:[EMAIL PROTECTED]
Sent: Monday, June 13, 2005 12:16 PM
To: Rod Macpherson
Cc: Info-cvs@gnu.org
Subject: Re: Removing Without Committing
Rod,
Information about pending removals (or modifications, for that matter)
is not stored
OT: IMO a dedicated machine for version
control is optimal and affordable so it is worth the effort to squeeze in a
single Linux box and use CVS proper versus CVSNT. That will also help
familiarize you with Linux. The primary stumbling block there is not the CVS server
but rather ensuring
Directories are never removed in CVS so recovery is required. I'm
somewhat confused about your objective. If you want to recover modules
(and of course the content) make sure you have a tagging policy that
works for you. You can then restore using a checkout and if necessary
check it back in
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Rod Macpherson
Sent: Wednesday, June 08, 2005 8:47 AM
To: info-cvs@gnu.org
Subject: RE: Recovering from Attic
I meant to say Directories are never removed in CVS so recovery is
NOT required. I should
... recommend reading material ...
An apparently comprehensive discussion of CVS usage:
http://ldp.rtin.bz/REF/CVS-BestPractices/html/index.html
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
] *
* http://mlug.missouri.edu/~yolan/*
*AIM: YolanLINUX, YolanOTHER, YolanLAPTOP *
* ICQ: 74624109 *
*
* Doubling Technologies *
**
On Wed, 8 Jun 2005, Rod
If you have not already done so, the shared files should be part of some
independent module. A library with its own build script for example.
That way work on the library requires an explicit module checkout.
Concurrent checkouts should not be a problem with or without
notification. That's the
Configuration Management typically referred to as CRM for Configuration
and Release Management. I think Linux is pretty high profile and then
there are approximately 100,000 (count 'em) project on SourceForge that
all use CVS. I think it's safe to say it's the #1 VCS in the world. The
list of who
What purpose does the update A switch serve other
than to switch you back to the HEAD of trunk after creating a branch? With the
exception of that narrow use case it seems to be dangerous and confusing. It
also seems to be redundant as there is a more general way of switching branches
and
It [Update -A] also reverts any local -k options back to the
repository defaults.
Good thing to know given it quietly does that in addition to merging
HEAD of trunk with your workspace.
I don't see what's dangerous or confusing about it, it's a quick way
to
throw away any local
I use the following command form to merge a range of changes
from one branch to another. Is this range behavior documented? The cvs help
for update makes no mention of multiple j switches nor does checkout.
cvs update j source_branch_bookmark j source_branch
module
I run this
Amended report: the range feature is
document online however the help command does not indicate multiple j
switches are allowable.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rod Macpherson
Sent: Friday, May 27, 2005 12:51
AM
To: info-cvs@gnu.org
Subject
Title: Message
Have a bunch
of files that were added today at 11:24 AM PST and the date on the repository
images concurs. Checking out those files generate a "Warning: modified in
future" and a check of the log indicates the files were added at 7:24 PM PST.
The client and server clocks look
Title: Message
I have
asub-treefoo and I want to move it from/old/foo to /new/foo
where "old" is a top-level module and "new" is a top-level module.
1. Create a copy
of/old/foo in /new/foo using cvs export.
2. Physically remove
the files in/old/foo while preserving the CVS folders.
3.
Title: Message
To clarify the
movement of files, when you remove a file X from module /foo then add file X to
module /bar CVS will assume you meant to move the file provided you did not
commit. In general I do not want CVS to assume a relationship between
afile X that was removedand a file
Message-
From: Paul Sander [mailto:[EMAIL PROTECTED]
Sent: Monday, October 06, 2003 1:01 PM
To: Rod Macpherson; [EMAIL PROTECTED]
Subject: Re: CVS File Move
CVS never assumes you want to move the file. In this case, it assumes
you want to remove a file from one place and add a new file
Title: Message
Apologies in advance
if this is the wrong mailing list but it's the only one that looked promising.
We have
abase set of files that we customize on a per-client basis. Each client
has a mirror image of the base directory structure. Each client does not have a
mirror
31 matches
Mail list logo
