Re: What is a module?

[Pierre Asselin]

ps <[EMAIL PROTECTED]> wrote:
> Reading the cvs documentation I can't get past the first few lines. 
> Nowhere can I find the definition for "module". The docs freely start in 
> referring to modules everywhere, but the term is never exactly defined.

Yeah, it's a little ill-defined.  Loosely speaking, a module is any
part of the tree under $CVSROOT that can be checked out as a unit.
For example, immediately after you do your "cvs init" there is a
$CVSROOT/CVSROOT subdirectory with cvs administrative files,
and you can check it its contents like so:

cd some/place/clean
cvs checkout CVSROOT

In that sense, CVSROOT is a module.  After you import a few trees,
every top-level directory under $CVSROOT is a module because you can
check it out by name.

In that same CVSROOT administrative sandbox, you will find a "modules"
file.  You can edit that file to make other subtrees of your repository
accessible by name, like the top-level subtrees.  An entry like this,

scripts-A   projectA/lib/tools/subtools/scripts

makes a deep subdirectory available through

cvs checkout scripts-A

So there is a somewhat more precise definition:  a module is anything
that has an entry in $CVSROOT/CVSROOT/modules .

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Recover a working copy

[Pierre Asselin]

Robert D. Young <[EMAIL PROTECTED]> wrote:

> When I import, the existing CVS revision info is lost (or appears to be,
> with everything at 1.1.1.1).

The substitution is done on checkout, not import.  If you specify "-ko"
on the checkout command line, your working copies will come out with the
original strings.

Not that it will necessarily do you a lot of good ...  You still have
only one revision's worth in your repository.

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: need to force username of cvs 'action' when using shared SSH account

[Pierre Asselin]

TG <[EMAIL PROTECTED]> wrote:

> Here is the issue:  I noticed that the name of the committer for each
> file that I committed was unix account id, or the one that is used to
> SSH into the cvs machine.  Now I have multiple developers(committers)
> and ONLY ONE shared shell account on the machine where is CVS is
> running.

Is there a reason why you can't use the old-fashioned strategem
of one account per developer ?


> I need to be able to force a unique name for each developer
> that CVS will log.

> Here is what I've tried so far:

> A. In front of each developers public key, I placed:

>   command="/home/mydomain/bin/setuserscript
> theuser",no-port-forwarding,no-pty

You can also use $HOME/.ssh/environment on the client side to tunnel
environment variables of your choice.  I've never tried it myself, I
just saw that in the ssh man page.  (Your developers would be able to
cheat, though.)  The trouble is, CVS doesn't look at the environment to
decide who's calling.


> There HAS to be a way to force cvs to record the correct committer
> name.

Why ?  Why would cvs extract that information from a source other than
its own euid ?

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: need to force username of cvs 'action' when using shared

[Pierre Asselin]

Tim Grotenhuis <[EMAIL PROTECTED]> wrote:
> I am not allowed to run pserver.

Not even on a nonstandard port, tunneled through ssh ?

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Fw: need to force username of cvs 'action' when using shared

[Pierre Asselin]

Larry Jones <[EMAIL PROTECTED]> wrote:

> What you're doing (using a single account for everyone) is what is
> compromising the tracking.  What you're asking for would completely
> compromise the tracking since it would allow absolutely anyone to commit
> changes whilst claiming to be anyone else they like.

Actually, Tim might be able to preseve accountability if he keeps full
control of the public keys.  Each private key allows one developer to run
exactly one command, which sets that developers environment variable and
execs "cvs server" (so I guess the developers also need to tweak their
CVS_SERVER variable at the client end).

But CVS doesn't have an environment variable to fake the userid.
Seems that Tim would have to hack CVS and get a copy installed on the
colocated server, in his private tree if necessary.  After that, he'd
better lock down the CVSROOT/ module, otherwise his developers could
manipulate the authorized_keys file through loginfo and other hooks.
What other holes are there?  Is it worth the trouble to chase them
down?

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: RES: Checking out only files NEWER than given date/revision

[Pierre Asselin]

Alek Lapuc <[EMAIL PROTECTED]> wrote:

> The reason is simple. At the begining of the project we had some
> sources and include files supplied "out-of-the-box" with a commercial
> product. Than we done some customizations -- some files were added,
> some were changed, some were untouched.

> The main idea is to filter out the untouched files, so they are
> separated from out-of-the-box ones.

> The reason for this is that files out-of-the-box can be automatically
> patched while patching the whole product with official patch. The
> patch is prepared outside to our project. Our changes are not known to
> the product vendor, and most propably would be corrupted during such a
> patch. But having original and customized files separated, we can
> apply the patch and merge it manually to our sources if needed.

Tracking third party sources in the presence of local changes is what
the 'cvs import' command does.  The external sources are usually
delivered as tarballs or zip archives, but applying patches will work
too.

So check out your last import tag, patch it, reimport the result
and merge your trunk.

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Module weirdness.

[Pierre Asselin]

Carter Thompson <[EMAIL PROTECTED]> wrote:

> I have some really strange problems with my repository.

> I have the module "adm" with a subdirectory "ui".  I also
> have a module named "ui".  Both are part of a module alias,
> "adm-suite".  That is,

> == Modules ==
> adm-suite adm &ui
> adm   adm
> uiui

Your $CVSROOT/adm/ui/ collides with the ui/ that the &ui is trying to
create.  You can't do that.  It will *not* give you the union of
$CVSROOT/adm/ui/ and $CVSROOT/ui/ .  It just breaks.

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Personal CVS repository?

[Pierre Asselin]

J Krugman <[EMAIL PROTECTED]> wrote:

> For reasons that I'm not too clear on, my supervisor has instructed
> me that he must review my code before each submission to the off-site
> CVS repository, and he wants to do this once a week.

Then you have to play by those rules.  There may be intellectual
property issues.


> My only
> problem with this is that, even when I am the only programmer in
> a project, I prefer to keep a finer-grained version control than
> is possible with weekly submissions to the repository.

> It occurs to me, though, that maybe I could set up a "personal"
> CVS repository off my home directory

Yes, indeed.  Create a directory under you $HOME and run 'cvs init'.
You'll have to get familiar with 'cvs import' too.  Read the docs at
http://www.cvshome.org/docs/manual/cvs-1.11.15/cvs_13.html#SEC104 ,
slowly.  The first import is easy, the imports following that are more
complicated.

In your case, you'll want to keep yourself in sync with commits from
external developers.  Here's what I would do.

1)  Keep a checked-out sandbox from the public repository, preferably
from a read-only account so you don't commit by mistake and
bypass your weekly review.

2)  Import the said sandbox in your own private repository, to
the vendor branch.
outside-sandbox> cvs -d $CVSROOT import -I! -ICVS \
> path VENDOR import--mm-dd

3)  Checkout another sandbox from your private repo.  This is the
copy you work on.  Hack and commit normally.

4)  At review time, go to your inside sandbox, and
inside-sandbox> cvs commit
inside-sandbox> cvs tag review--mm-dd
inside-sandbox> cvs diff -N -u -rVENDOR > ../to_review.patch

Go over the to_review.patch with your supervisor.
If approved, apply the patch to your outside sandbox.
Commit from there, using a -d option to switch to the
developer account they gave you, with read-write permission.

outside-sandbox> cvs -d :ext:blahblah commit

Now there is the problem of keeping your outside sandbox up to date
(easy) and of propagating those changes to your inside sandbox
(takes some gymnastics).  At least every morning,

outside-sandbox> cvs update
outside-sandbox> cvs import -I! -ICVS path VENDOR import--mm-dd-1

That was the import.  Now the merge,

inside-sandbox> cvs commit
inside-sandbox> cvs tag premerge
inside-sandbox> cvs update -j  -j 
fix conflicts
inside-sandbox> cvs commit
inside-sandbox> cvs tag -d premerge

The 'premerge' tag is in case something goes wrong with the merge.  It
represents your last good point before attempting the merge.  If the
merge is full of conflicts, you can start a branch off of premerge to
continue your work while your figure out how to finish the merge.


> (although I'll readily admit
> that I've never set up a CVS repository of *any* kind before); I
> would use it for my "fine-grain" version control, while submitting
> new, boss-approved stuff to the "real" off-site repository only
> once a week...

> My knowledge of CVS is very limited; I know a few commands, and I
> never deviate from the most basic functionality.

The potentially hard part is all those imports and merges.  The bit
about setting up your own repository is really trivial.  One annoying
bit is that when you reimport your fresh commits to the external site,
your merge will show spurious conflicts with the same text on both side
of the conflict.  You'll just have to clean them up.


> This "personal"
> repository idea is far more "adventurous" than anything I've done
> with CVS before.

Yes, but it's the perfect thing here.  You commit to your private
repository at your chosen pace and you generate diffs at review time.

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: binary files bad idea? why?

[Pierre Asselin]

Jim.Hyslop <[EMAIL PROTECTED]> wrote:
> Spiro Trikaliotis wrote:
>> This is no problem from my experience if the initial check-in was done
>> from a Unix (LF-) based system, but it is a problem if it was 
>> done from
>> a DOS (CR/LF-) based system.
> There is also a remote possibility that the binary file might _happen_ to
> contain what CVS thinks is a keyword, such as $Id$. Chances are pretty slim,
> but it _could_ happen.

But the $Id$ expansion occurs on checkout.  The repository copy itself
would still be intact, and problems with the file would be fixed by a
"cvs admin -kb".  Working copies could be restored with "cvs update".

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS and end of line characters

[Pierre Asselin]

Jo Vermeulen <[EMAIL PROTECTED]> wrote:
> Op Wed, 26 May 2004 11:59:46 -0400, schreef Jim.Hyslop:

>> - Always modify files on the same platform you used to check them out. 

> Problem is, the people on my team use Windows, and I use Linux, so were
> kind of mixed :-)

Don't share the working copies.  You check out your copy on Linux,
edit it on Linux and commit it from Linux;  they check out their copies
on Windows, edit them on Windows and commit them from Windows.

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: line number to revision

[Pierre Asselin]

WannaLeanOO <[EMAIL PROTECTED]> wrote:

> Is there a command line tool or command that would quickly translate 
> filename + line number to revision number.

cvs annotate

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: listing new files in a local directory

[Pierre Asselin]

John Hanny <[EMAIL PROTECTED]> wrote:

> I'd like a cvs command that tells me what files in the current
> directory are new. One hack that I've been using is "cvs update." The
> files that are prefixed by '?' are new. Unfortunately, this has the
> side-effect of updating my local directory files if they have been
> changed in the repository.

Use the "-n" flag to turn off the side-effect.

cvs -nq update -I! -ICVS | grep \^\\\?

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Project in a cvs, library in another

[Pierre Asselin]

Ababccc <[EMAIL PROTECTED]> wrote:

> I'm wondering what people usually do, in case there is a project on CVS 
> which uses a C++ library which is in a completely separated CVS.

> If the library gets changed (for its own purposes) the project might get 
> screwed...

In cases like that, I equip the client project with a big fat README
file that explains how to check out a *specific release* of the
library in a subtree.  The subtree ends up with a sticky tag and a
normal "cvs update" doesn't affect it.

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: listing new files in a local directory

[Pierre Asselin]

Jim.Hyslop <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>> Use the "-n" flag to turn off the side-effect.
>> 
>> cvs -nq update -I! -ICVS | grep \^\\\?
> Why are you suppressing the ignored files? This could give a bunch of
> spurious "new" files that you want to ignore.

Because that's how I interpreted the OP's question.  I figured it would be
easier to get a full list and filter the chaff later, rather than to chase
files that were missed because they fell in cvs' default ignore list.

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Shared Source

[Pierre Asselin]

Chris Puccio <[EMAIL PROTECTED]> wrote:

> I need to be able to have one main "Core Product" code base, then be able to 
> suck down only certain pieces of that "Core Product" code base, which will be 
> the framework for another clients product.

Possible, with restrictions.  Bundle up the shared code in subtrees,
so any client product can get shared subtrees grafted under it, rather
than pick and select files at random.  It forces you to organize your
shared code, but that is probably a good thing.  Two recommendations:

1)  The "Core Product" should probably be a <> like
all the others.  Its only distinguishing feature would be that
it has all the shared subtrees under it.
2)  Each shared subtree should be a self-contained entity that
you can check out individually.  It should have its own test
suite, for example.  That way you can work on it in isolation
and later propagate the changes to the client products.
This doesn't preclude you from making the changes you want
from a "Core Product" sandbox, it just broadens your options.

> I then need to be able to have any 
> changes made to the "Core Product" be sync'd with any "Child" products that 
> received code from the "Core Product" code base.

The sync would occur every time you run a "cvs update" in a "Child"
sandbox.  Hmmm, notice how I've been using "client" instead of "Child" ?

> If anybody can give me some proper keywords on the CVS term to do this, it 
> would make googling much easier right now ;)

Amperstand modules.

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: up-to-date check failed from a lower revision to higher revision

[Pierre Asselin]

Antony Paul <[EMAIL PROTECTED]> wrote:
> I am new to CVS. I am using the cvs command line client in Linux. I have
> one file whose status is as follows
> cvs status: Examining .
> ===
> File: one.txt   Status: Locally Modified

>Working revision:1.4.1.3 Sat Jul 10 08:53:39 2004
>Repository revision: 1.4.1.3 /home/cvsuser/cvsroot/work/base/one.txt,v
>Sticky Tag:  1.4.1
>Sticky Date: (none)
>Sticky Options:  (none)

It is unconventional to have a numeric sticky tag ...

>Existing Tags:
> No Tags Exist

... and no symbolic tags.  Anyway,


> I started with version 1.1. I created a new version using the command
> cvs commit -r 1.4.1 one.txt

Are you sure that's what you did ?  When I try something similar, I get
$ cvs commit -r1.4.1 toto.c
cvs commit: Up-to-date check failed for `toto.c'
cvs [commit aborted]: correct above errors first!

It seems that you started with revision 1.4, not 1.1 as you said.
Either that, or the revision 1.4.1.3 in your status output is wrong.
It looks like you cut'n pasted the output of cvs status, so I'll assume
that 1.4.1.3 is correct and that your initial 1.1 was really 1.4 .


> Then I modified the file and committed several time using
  cvs commit one.txt

That part works.

> Now it is in revision 1.4.1.3. The error occurred when I committed with
> the following command
>  cvs commit -r 1.5 -m '1.5' one.txt
> What is wrong with it. I am the only person who works with this file and
> repository. I tried cvs update -C one.txt. Still it is giving error.

To finish off and make revision 1.5, commit one last time to the branch,
return to the trunk and merge your branch.

cvs commit  # creates rev 1.4.1.4
cvs update -A one.txt   # returns to rev 1.4 and removes the changes
cvs update -j 1.4.1 one.txt # pulls in the changes
cvs status -v one.txt

The status should look something like this:

File: one.txt   Status: Locally Modified

   Working revision:1.4 Result of merge
   Repository revision: 1.4 /home/cvsuser/cvsroot/work/base/one.txt,v
   Sticky Tag:  (none)
   Sticky Date: (none)
   Sticky Options:  (none)

   Existing Tags:
No Tags Exist

The file contents will be that of revision 1.4.1.4, as if you had
checked out a fresh copy of 1.4 and manually edited 1.4.1.4 into it.
Hence the status of "Locally Modified".  Just commit the result.

cvs commit  # creates rev 1.5 .

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Multi-tier development CVS plan

[Pierre Asselin]

adp <[EMAIL PROTECTED]> wrote:
> Did you get a response on this? We are looking to move from a single CVS
> branch (MAIN) to either a two- or three-tiered system. Would be happy with
> hints.

> We are thinking of this:

> unstable -> stable -> release

The usual way to handle this on CVS is an unstable trunk with
stable+release branches.

++unstable>
 \\
  \stable1-|-| \
  rel-1.1  rel-1.2  \
 \---stable2---|->
 rel-2.1

Every time your unstable trunk reaches a milestone, you cut a
stabilization branch.  On this branch you perform only cleanups and add
no new features.  Eventually you tag your stabilization branch and cut
a release, after which the branch becomes a bugfix branch.  Promoting
a new batch of changes from "unstable" to "stable" is done by starting
a new stable branch.

Not shown on the diagram is how the bugfixes from maintained release
branches would be merged to later releases and to the trunk, but
that's standard CVS fare.

You *might* make the original promotion model work in CVS with floating tags:
cvs tag -F -r1.6 STABLE toto.c  --oops no, cvs tag -F -r1.5 STABLE toto.c
etc.  You could then check out with the -rSTABLE flag to get an
official "stable" tree without the unstable riff-raff.  That said, I
don't understand the promotion model well enough to give you sound
advice.

To recap:

> unstable:
> This is where our current development goes.

The trunk, also the default.


> stable:
> This is where we merge our soon-to-be-released code so that QA can begin
> work.

You don't really "merge" in the CVS sense, instead you fork a branch
to isolate changes on it from the unstable trunk.

> release:
> This is where we merge from stable, tag an official code release, and then
> push the release.

You could branch the stable branch, but ususually it's easier to just
tag milestones on it.

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Setting up a new CVSNT or Linux server ??

[Pierre Asselin]

Frederic Brehm <[EMAIL PROTECTED]> wrote:

> [ case-sensitive client with case-insensitive server]
> In your scenario, it appears to me that the only failure comes with the 
> CVSNT server and UNIX client. In that case, the user knows that there are 
> two separate files "file" and "File" in the directory and CVS should be 
> able to add both but it refuses.

But allowing the add would be worse for the developers on
case-insensitive clients.  For them, the next update would yield
endless messages to "move File, it is in the way".

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Import question

[Pierre Asselin]

Lemke, Michael  IZ/HZA-IOP <[EMAIL PROTECTED]> wrote:
> When I do a cvs import of a new vendor version the new files become the
> head revision.  I'd like to do the import such that it doesn't affect HEAD.
> Only after I've tested the new stuff I want it to become HEAD.  Of course,
> it should work with local changes merged in just like the standard way of
> doing it on the trunk.  How can I do this?  

There is no way to avoid that.  Your trunk is broken between the time
you do the import and when you merge the import back to the trunk.

To mitigate the problem, you should tag your trunk before you do the
import.  If the post-import merge gives you trouble, you can at least
start a branch off your pre-import tag so you can continue your work
in another sandbox while you sort things out.  When you finally merge
the import, you go on to merge the temporary branch.

-- 
pa at panix dot com
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: ***glaring*** flaw in cvs import?

[Pierre Asselin]

Robert P. J. Day <[EMAIL PROTECTED]> wrote:

>following the instructions in "tracking third-party sources", i 
> downloaded a kernel source tree that i both want to update regularly 
> from the source, and make local changes to.

>i pulled down the tree, cleared out all CVS directories to turn it 
> into a regular directory tree, then used "cvs import" to check it into 
> my local repo.

Ok, so you checked out a tree from a public CVS server and you want
to import that locally.  You don't have to remove the CVS/
subdirectories.  See below.

>in the process of doing that import, the "cvs" command apparently 
> decided it didn't much care for the kernel source directory 
> net/bridge/core, and threw it away!  why?  because it's called "core"?

Because 'core' is in the default ignore list.  I usually reset the
ignore list to just 'CVS', like this,

cvs import -I! -ICVS  VENDOR 

and then check out a fresh sandbox somewhere else.

You can keep the original external sandbox untouched;  that way, you
can update it from the public CVS server and reimport any deltas to
your internal server.


-- 
pa at panix dot com
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Get the list of all modules of a given repository

[Pierre Asselin]

Miguel Lopez <[EMAIL PROTECTED]> wrote:
> is there a cvs command that allows to retrieve all the modules of a 
> given repository?

If you mean "the list of modules defined in the CVSROOT/modules file",
then
cvs checkout -c

-- 
pa at panix dot com
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: any CVS clients, with a good user interface

[Pierre Asselin]

shivraman giri <[EMAIL PROTECTED]> wrote:

> I have my repositories in UNIX.
> I m working on a machine with windows XP installed.
> Is there a good CVS client, preferably a freeware, trial version
> or a GNU product that gives a graphical user interface for running
> CVS commands.

http://www.tortoisecvs.org/

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS Permissions

[Pierre Asselin]

Gaurav Vaish <[EMAIL PROTECTED]> wrote:

>   I am using pserver to connect and more often than not, I get the
> error - "Unable to create #cvs.lock, Permission denied".

>   The reason is that a module or a subdirectory thereof will be
> created by the permission set of the permission who created it. Though
> the directory permissions are 775 and all the users are in the group
> "cvs", but still the problem persists.

I'm lost.  775 is the correct permission.  Are you saying all the
directories have that permission and you still have problems ?

If subdirectories are being created with more restrictive permissions,
it means that you forgot to turn on the setgid bit in their
parent's permissions.

-- 
pa at panix dot com
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Aliasing the trunk with a branch tag

[Pierre Asselin]

Keith Refson <[EMAIL PROTECTED]> wrote:
> One problem I regularly face is: how to build two different versions of
> a project which differ in only a very small subset of files.  One of
> these versions is obviously the trunk version.  It would be extremely
> convenient if this could be achieved by simply

>cvs co (or update) -A myproject
>cvs co (or update) -r Version_B myproject

> to switch between them.
> [ ... ]
> I recenty came across a suggestion of how to do this, and it does work
> when I tried it out.  The idea is simple - just add the branch  at the
> numeric version "1":

> cvs admin -nVersion_B:1

> [ ... ]
> I'm asking for any opinions on whether this is a safe thing to do, and any
> potential difficulties, mild or severe, which might arise.

It should be ok, but I'm always weary of long-lived branches.
After a while you might want to re-graft your branch higher up on
the trunk (for the files that do change).  If you don't see what
I mean, do an advanced search on groups.google.com for Message-Id
"[EMAIL PROTECTED]" .

-- 
pa at panix dot com
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: How make cvs import

[Pierre Asselin]

pierre <[EMAIL PROTECTED]> wrote:
> Hi I want to use CVS for my project, olso I make and cvs init an cvs 
> import  for the first init.
> My problem is that I must be root for make a checkout, and all the files 
> are owned root. I must change the owner for edit them.
> How make and cvs import in not administrateur login ?

Hmmm, "root" sounds like Unix and "administrateur" sounds like
Windows...  Assuming a Unix-oid box below.

You must have done the init and the import as root.  If you have
only one normal user, just change the ownership of your $CVSROOT
tree to him, recursively.  If you have many users, create a "cvs"
group and put all your users in that group;  for symmetry, create
also a *user* "cvs" and put him in the cvs group;  change the
ownership of all *directories* in the $CVSROOT tree to user cvs,
group cvs, and change the *directory* permissions to 02775 (owner
rwx, group rwx, other r-x and setgid).

The file permissions are probably 0444 and can stay that way.  It's
the directory permissions that matter most.

-- 
pa at panix dot com
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Checkout./export a copy to /var/www

[Pierre Asselin]

Anand Graves <[EMAIL PROTECTED]> wrote:
> I use WinCVS to checkout a copy on my PC. When I do a commit, the file
> checks in a linux server. I would like a committed file to be checked
> out/copied/exported to /var/www/myproject.

> When I search for this, I keep finding this (for the loginfo file):
> ^cyclic-pages   (date; cat; (sleep 2; cd /u/www/local-docs;
>  cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1

> But this will update the checked out tree in `/u/www/local-docs' and my
> checked out tree is on a windows PC.

The checked-out tree is on Windows and the cvs repository is on a
Linux box, but where is /var/www ?  That sounds like Linux too.  If
your web server is also your cvs server, just change the
"/u/www/local-docs" in the example to "/var/www/myproject" and you're
done.  The commit on Windows triggers the loginfo on the Linux server,
which triggers the update on the Linux server.

If the web server is another box, you need to make loginfo trigger an
update *from the web server*.  If the web server is Linux (/var/www ?)
the standard solution is ssh, which when properly setup allows someone
on the cvs server to run commands on the web server.  If the web
server is on Windows...  well, I'd install Cygwin
(http://www.cygwin.com) and still use ssh but that's just me.

-- 
pa at panix dot com
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Question

[Pierre Asselin]

Gleidson S? Barreto <[EMAIL PROTECTED]> wrote:

> 1-To take place the transfer of the files stored in
> the repository q they were modified for your work
> area, through a sicroniza??o operation. Like this,
> would to be in fact that sicroniza??o operation? 

I'm not sure what you mean, but...  Synchronization in both direction
has to be requested explicitly, by running a command.  "cvs update" to
receive changes made by others, and "cvs commit" to send changes made
by you.


> 2-CVS counts with a mechanism capable to control the
> simultaneous accesses and the parallel modifications,
> guaranteeing like this the integrity of the
> modifications and atomicity of the operations. Would 
> be in fact that atomicity of operations? 

If I remember correctly, commits are atomic within any one directory
but are not atomic across entire hierarchies.  Commits are certainly
atomic on a file by file basis, so you do not get corrupted files.

The lack of atomicity occurs when a developers performs an update
(receive) while another developer performs a commit (send).  The
receiving developer may get an inconsistent snapshot with some files
just before their commit and some other files just after the commit.
The workaround is to repeat the update.  It would be a little
difficult to notice in practice, because when working on an active
project one has to update many times every day.  Also, the trunk
tends to be somewhat unstable since it is being actively modified.


> 3-CVS possesses mechanism capable to identify and to
> solve conflicts. However those identified conflicts
> are merely textual, not existing any analysis of the
> logical consistence. Here I didn't understand the
> expression textual conflicts very well. 

A "textual" conflict occurs when two people modified lines at overlapping
locations in a file, or at nearly overlapping locations (~3 lines
apart or so).  These conflicts have to be resolved manually.

Modifications in distant parts of the file are accepted uncritically.
You are correct that this could introduce logical errors in the merged
file;  the amazing thing is that it almost never does, because of the
way people write software.

In any case, cvs always gives you backup copies of the two conflicting
versions of the file.

-- 
pa at panix dot com
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Merging Issues

[Pierre Asselin]

Dhruva B. Reddy <[EMAIL PROTECTED]> wrote:
> We are doing development on a branch which has been around for a while,
> and I was required to merge in changes from the trunk a few times.

> The first time I did this, I did the following (in a sandbox from the
> branch):

> cvs up -j HEAD

> and then applied a tag as recommended by the documentation.  This merge
> went as expected (changes made on the trunk were now available in the
> branch, along with the changes checked into the branch).

> A few days ago I merged changes from the trunk again.  I could have
> sworn I did it like this (again, in a sandbox from the branch):

> cvs up -j  -j HEAD

> This resulted in the loss of *all* changes made on the branch (i.e.,
> they were overridden by the versions on the trunk).

> Can anyone tell me what could have caused this (what kind of human
> error, etc.) and how to prevent from happening again?

My guess:  when you planted the  you
tagged the branch by mistake, instead of tagging the trunk.  That
would explain why the second merge undoes all the branch work.

Workaround:  don't commit this sandbox where you attempted this
second merge, just delete it and start over.  Now go back to the
trunk and create a new branch.  Get on the new branch.  Merge
the changes on the old branch,

cvs update -r 
cvs update \
-j <1st-branch-branchpoint> \
-j 

and go fix the conflicts.  You have to expect vacuous conflicts,
because many changes between <1st-branch-branchpoint> and the tip
of the old branch are also present on the trunk.  The conflicting
text will be the same on both sides, so just pick one.  Sometimes
cvs (diff3, really) manages to get it right but as a rule you
have to expect spurious conflicts.  Well, fix them, that's the
price you'll have to pay.

Commit the new branch, and abandon the old branch.

-- 
pa at panix dot com
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Preventing "Dirty" Checkins

[Pierre Asselin]

Ones Self <[EMAIL PROTECTED]> wrote:

> I'm running a CVS server which compiles and tests the current
> files in CVS every hour.  I would like to make new checkins
> available _only_ if they compile and pass the tests.

> So, if a user checks in something which does not compile, for
> example, other users who check out at that time will not get
> the new version until the problem is fixed.  Everytime you
> do an update, you know you're getting a clean version of the
> source; one that compiles, and in which the tests pass.

I don't think you can do that.  Well, you could trigger a full
recompile from commitinfo and allow the commit only if the build
succeeds, but your commits would be a bit sluggish that way.

What you *could* do is trigger the build from loginfo (post-commit)
and update a moving tag if the build is successful.  That way
your trunk can contain garbage, but the last successfully built
commit will have an unambiguous marker on it.  Your users can
choose the unstable tip,
cvs checkout foo

or the last known good version,
cvs checkout -rLAST_GOOD foo

but in the latter case they won't be able to commit changes.
(Well, they could start a branch, but that's taking us off-topic.)

The loginfo trigger would be asynchronous, as in
https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC175
and there would be negligible delay to a commit.

Simple question:  why can't the developers do a top-level "make test"
before committing, and sidestep the question ?  Or do the unit tests
take that long to run ?  If the latter, you'll have to guard your
build-test-retag script against multiple instances of itself.

-- 
pa at panix dot com
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Preventing "Dirty" Checkins

[Pierre Asselin]

Maarten de Boer <[EMAIL PROTECTED]> wrote:
> > What you *could* do is trigger the build from loginfo (post-commit)
> > and update a moving tag if the build is successful.
> > [ ... ]

> But why would you to that from the loginfo? Wouldn't it be easier to
> have that tag moved by a virtual user, the dedicated test build machine,
> which is building and testing in a loop, everytime the compilation is
> correct?

Hm, my language was ambiguous.  What the loginfo would trigger is
one script, running on the test machine, that updates the test sandbox,
builds, runs the tests, and finally moves the tag if the tests pass.

-- 
pa at panix dot com
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Using moving tags

[Pierre Asselin]

Yamuna Ramasubramaniyan <[EMAIL PROTECTED]> wrote:
> I have a question about using moving tags.  You tag
> the repository with LAST_GOOD today.  Someone removes
> a file.  This file still contains the LAST_GOOD tag. 
> The next person checking out the module with the
> LAST_GOOD tag will get this deleted file.  Do you use
> a commitinfo trigger to remove the moving tag from the
> deleted file?  Are there any other ways to handle this
> case?

D'oh.  I hadn't thought of that.  Maybe the tag mover could look
for files that are 1) dead on the trunk, 2) not added on a branch,
3) still have the tag;  and then remove the tag from those files.
Not so easy to do from a sandbox from which the file has been
removed.

Well, it wasn't my requirement so I'm still ok ;-)

-- 
pa at panix dot com
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Preventing "Dirty" Checkins

[Pierre Asselin]

Robin Rosenberg <[EMAIL PROTECTED]@dewire.kom> wrote:
> Pierre Asselin wrote:
> > Hm, my language was ambiguous.  What the loginfo would trigger is
> > one script, running on the test machine, that updates the test sandbox,
> > builds, runs the tests, and finally moves the tag if the tests pass.

> Trigging rebuilds for every commit is insane. 

Well, the OP wanted to trigger a test build in the pre-commit check.
I was proposing a less heavy-handed solution.  Not that it's entirely
free of "gatchas".

> [ sane process elided ]


-- 
pa at panix dot com
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Using moving tags

[Pierre Asselin]

Doug Lee <[EMAIL PROTECTED]> wrote:

> Er...now maybe I'm the one missing something.  I don't see the
> problem:

> Say the LastGood tag was applied on Monday.  Tuesday someone removes
> a file and commits that, but LastGood is not moved yet.

But the tag *is* moved, if the testing robot succeeds with its
post-commit build.

If it weren't for deleted files, the robot could be just this:

#! /bin/sh
cd /the/reference/sandbox
cvs update
make test && cvs update -F LastGood

If files are removed, that's not enough.

-- 
pa at panix dot com
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: setting up branch with code changes already in it

[Pierre Asselin]

Royce <[EMAIL PROTECTED]> wrote:

> (from top directory within tree)
> cvs tag v2_0_unstable_root
> cvs tag -b -r v2_0_unstable_root v2_0_unstable

followed by
cvs update -r v2_0_unstable

> I have not checked in the files because I wanted to be sure they will
> check into the branch. How can I verify the code will check into the
> branch?

I'd do a 'cvs status | less' and make sure every file has the
sticky tag.  Maybe also 'cvs -nt commit' (-n to block the actual
commit, -t for a trace of what would happen), but I'm not sure
that will show you what revision numbers would be used by a
real commit.


> cvs log doesn't seem to show that info. I read somewhere that
> the branch gets created on commit - is that true?

Yes, if you really commit to the new branch.

-- 
pa at panix dot com
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: DOS Command to get current branch?

[Pierre Asselin]

Talos <[EMAIL PROTECTED]> wrote:

> My question is:  Is there a DOS command that let's you know what
> branch name the sandbox you're currently is?

Run "cvs status " and look for any "sticky tag"
listed in the output.  If your sandbox is on the branch, you'll see
your branch name there.  If you're on the trunk, it will be empty.

Of course that only checks the one file, not the entire sandbox,
but if you only tag and branch entire projects it's a good
sanity check.

(This assumes that you have cvs or cvsnt installed somewhere
on your path as "cvs.exe'.)

-- 
pa at panix dot com
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Merging question - from and to

[Pierre Asselin]

Jeeva Sarma <[EMAIL PROTECTED]> wrote:

> I have a file soa.pc, branched out at 1.2, now at
> revision 1.2.4.1 on branch, and 1.2 on trunk. I
> check-out from trunk, then do

> [ ... ]
> cvs update -j 1.2 -j 1.2.4.1 soa.pc

Yes, like that.  The command means, merge all changes
that occurred between 1.2 and 1.2.4.1 into the working copy,
which is what you want.

What is confusing you is that there are *three* revisions involved:
the base of the changes to merge, here 1.2, the endpoint of the
changes to merge, here 1.2.4.1, and the working copy, which doesn't
need to be called out by revision because it is the file sitting
in your sandbox at the moment.  In your case, the working copy is
identical to the base, but this isn't always true.


> RCS file:
> /cvsrep/cvsroot/ACE/ace/audit/care/soa/soa.pc,v
> retrieving revision 1.2
> retrieving revision 1.2.4.1
> Merging differences between 1.2 and 1.2.4.1 into
> soa.pc

After which the soa.pc in your sandbox should be identical
to 1.2.4.1, but once again this was a special case because
your starting point was identical to 1.2 .


> cvs update -j HEAD soa.pc
> RCS file:
> /cvsrep/cvsroot/ACE/ace/audit/care/soa/soa.pc,v
> retrieving revision 1.2
> retrieving revision 1.3
> Merging differences between 1.2 and 1.3 into soa.pc

If you omit the first "-j", it defaults to the most recent
common ancestor of the given "-j" and of the working copy.
Here HEAD means 1.3, because you or someone else committed
changes after you checked out the sandbox with 1.2 .
The common ancestor of 1.3 and 1.2 is 1.2 so once again
you end up with a special case where the base and the
working revision are identical.  You are grabbing the
changes from 1.2 to 1.3 and injecting them in 1.2,
the result being identical to 1.3 .

BTW, if you lose track you can always do
rm soa.pc
cvs update soa.pc

to get a clean copy of the HEAD of the moment.

-- 
pa at panix dot com
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: history of version changes

[Pierre Asselin]

Saad Sheikh <[EMAIL PROTECTED]> wrote:

> I am a new to CVS. I wanted to know if there is a command that will
> list all the versions of a project.

There is a perl script, "cvs2cl.pl", that consolidates the log
messages of a sandbox in chronological order.  Try Google.


> I wanted a history of versions of the project AND the files that have
> changes from one version to the next, like the history command in VSS.

>From the VSS comment I infer that you're on Windows.  If cvs2cl is
the right solution you'll have to install perl first, either by
Cygwin or from www.activestate.com .  It can get messy.  I always
find it painful to integrate new tools into Windows "integrated"
environment ...  Different culture, partly.

For what it's worth, I run cvs2cl.pl from Cygwin all the time.

-- 
pa at panix dot com
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: how to check out a project which contains modules from different branches

[Pierre Asselin]

Li Chou <[EMAIL PROTECTED]> wrote:

> Hi, I tried to figure out a single step of check out a project that
> contains modules from different branches of different project.

> For example, Project X has 3 modules, A and B which are from other
> projects.   I need to check out module A's of Project Y branch_2.5,
> and module B of Project Z's main trunk.  If they both were in the
> main trunk, I know I could add "X C &A &B" in modules file.  Now
> how do I check out them both at the same time?  is it possible?
> Thanks

Would a two-step process work for you ?  Recently I've been thinking
about a "wrapper" project.  Something that would work thus:

$ cvs checkout X-wrapper
U X-wrapper/README
U X-wrapper/checkout.sh

and the README file would say:
Run "sh checkout.sh" to get the rest of the tree.  Bye.

The checkout.sh script would contain these commands,
cvs checkout C
cvs checkout -r branch_2-5 A
cvs checkout B

and by running it you would get the correct revision of
each subtree.  The script is rev-controlled, so it can track
changes in branch tags when subprojects get merged to
their trunks.

I guess this sort of thing (programmability) comes more
naturally in *nix.  Bah, even Windows lets you write
a checkout.bat, so it will work there too.

-- 
pa at panix dot com
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: keyword for branch-name?

[Pierre Asselin]

"Voigt, Ulrich" <[EMAIL PROTECTED]> writes:

>Is there a keyword for the branch-name of the currently checked out file? I
>want to use it in a version file, in which I have to print the branch name.

The closest thing is $Name$, but

1)  It expands only release tags, not branch tags.
2)  The expansion occurs on checkout -rTAG or export -rTAG,
but not on update -rTAG.

This is from memory, I may be wrong.  If you need the branch
information, you'll need to extract it in a build script using cvs
status.  And that will only work from a checked-out sandbox, not an
exported tree.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Vendor Tag & Release Tag

[Pierre Asselin]

eric07 <[EMAIL PROTECTED]> writes:

>What are these used for.  Using WinCVS and when importing there is a
>Initial vencor and release tags section 
>with Vendor tag: avendor ( this is the default value )
>Release tag: arelease ( this is the default value )
>what do they mean as far as usage?

The vendor tag is cruft.  Normally there is only one vendor branch
(1.1.1) and the vendor tag just refers to it.  Pick some string that
you'll never forget and use that.  `avendor' is fine.

The release tags *are* important.  Pick something that describes
the distribution you are importing, e.g. `psutils_1_16' or `Mesa_3_4'.
When you import a new release, use an appropriate successor tag,
e.g. `psutils_1_17'.  If you made local changes, you will need
these release tags to merge them into the new release.  See the
manual.

If you are importing *your* sources, make up some release tag.
You will probably never use import again so the release tag isn't
too important.  Just pretend.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Ye olde issue of symlinks

[Pierre Asselin]

Simon Perreault <[EMAIL PROTECTED]> writes:

>We are programming a WWW administration interface (think Webmin), and so 
>there are project files scattered all over the test machine's filesystem. 
>What we do is that every programmer has its own development machine (be it 
>VMware or physical) and mounts every partition using NFS. Then we have our 
>personal ~/cvs directory which contains tons of symlinks to files and 
>directories on the NFS-mounted partitions.

You are trying to share ,v files across multiple repositories using
symbolic links and NFS mounts?  Be glad it doesn't work!  If it did,
you would soon corrupt your repositories due to missed locks, not to
mention  NFS bugs.  You're also trying to manage entire filesystems
with CVS, and that doesn't work well.

What you need:
1)  A central repository, accessed through pserver or ext,
*not* NFS mounts.
2)  Sandboxes for each developer.
3)  A simple `make install' step that copies files from the
sandbox to all over the development machine's filesystem.

Your approach was common with RCS, but CVS is different.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS & a Web site

[Pierre Asselin]

Jason Purdy <[EMAIL PROTECTED]> writes:

>What is a good scheme of automating synchronization between a CVS repository 
>and a Web site
>[...]

>2) Create 'trigger' scripts which would be triggered when the developer 
>'commit'ed their changes, which would also affect the changes on the Web site 
>directories.

Yes, like that.  It's documented in the manual.  Try searching for
"Keeping a checked out copy".  You could tweak the approach therein
to keep an exported copy instead.

Also, it would be a *really, really good idea* to run multiple copies
of the web server, one for each developer sandbox, each running on a
private high-numbered port.  That way, the developers can browse and
debug their sandboxes before committing.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Identifying the head revisions currently in main

[Pierre Asselin]

"Sherman Tse" <[EMAIL PROTECTED]> writes:

>I'd like to do an rdiff between one of my branches in the cvs and the head 
>revisions in the main trunk.  Is there a way to do that?

If your trunk revisions are all of the form 1.x , the trunk is effectively
a "branch" with branch number "1".  So,

$ cvs diff -r1

You can also try

$ cvs diff -rHEAD

but I'm not sure of the exact semantics if your sandbox is on a
branch...

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Forcing the date on a check-in

[Pierre Asselin]

[EMAIL PROTECTED] (Paul DeWolf) writes:

>I'm in the process of moving from SourceSafe to CVS, and I'm writing a
>Python script to convert from one to the other.  (The website with the
>vss2cvs Perl script seems to not be available anymore).

>I want to keep the old dates of the file versions, so I want to be
>able to commit a version to CVS, explicitly setting the date/time
>instead of using the current date and time.

>Is there a way to do this?  

If you're willing to build the ,v files with RCS commands instead
of cvs calls, the ci(1) command has a -d option that would do what
you want.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS Sharing

[Pierre Asselin]

"Jason Mowat" <[EMAIL PROTECTED]> writes:

>I would like to know if this is one area that =
>CVS can do (VSS can do it): sharing.  In Visual Source Safe, you can =
>share a single file among projects.  When the shared "centralized" file =
>changes, it changes in all the projects.  When the shared file in a =
>project changes, it changes all related files in other projects by =
>updating the centralized copy.

You can do that in CVS, if you are willing to share entire directories
or directory trees as opposed to isolated files.  Use submodules
("amperstand modules") in the modules file.

You may need to reorganize your source tree to avoid mixing shared
and non-shared files.  In any one directory of a checked-out sandbox,
all the files must originate from a single directory in the repository.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: How do you work out "automatically" the set of branches and the latest version of each branch within a CVS project ?

[Pierre Asselin]

"James Ball" <[EMAIL PROTECTED]> writes:

>I need to work out the set of branches within a given project, and the
>latest "version" expressed by the latest TAG for each branch within a
>project.  From what I've read there doesn't seem to be any obvious way
>to do this, which is puzzling given knowing what code you've got  is
>normally a given, or at least essential.

Yeah, isn't that a bummer!

>From a checked-out sandbox you can do a `cvs status -v README'
(substitute a random existing file for README) to list all the tags
and branches *on that one file*.  It's generally a bad idea to branch
individual files, so hopefully the list applies to the entire project.

Without a sandbox, I think you need a shell account on the machine
that holds the repository.  You do a plain RCS "rlog README,v" and
extract the branch list form the output.

To the list:  does cvsweb provide a solution to James' problem?

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: How to import with some binary files?

[Pierre Asselin]

"Chris Bailey" <[EMAIL PROTECTED]> writes:

>I have a bunch of files I want to add to add to a new CVS module.  The
>problem is that some of the files are binary, and some that are binary
>don't have file extensions (this is on Linux, with CVS 1.11)

Is it third-party source, or is it your source tree and you're only
using import for convenience?

If it's your source tree, you could move the binaries out of the way,
do the import, check out a sandbox, copy the binaries into the
sandbox, and cvs add them with the -kb option.

If this is really a third-party source tree, you could import from
Linux and manually do an `rcs -kb' on the repository files (assuming
you have a shell account on the cvs server).

You could even check out a sandbox on Linux and do a cvs admin -kb
form there.


>[...]  But, I've added plenty of .gif files to our repository
>with just a straight "cvs add file.gif", and it works fine.  Our
>cvswrappers file does not have anything in it right now.  How is this
>working?

The -kb does two things:
1) turn off line-ending conversions;
2) turn off the expansion of RCS keywords.

If you only work on Linux, (1) is a no-op anyway.  Your .gif files
must not contain any byte sequences that look like RCS keywords,
so (2) hasn't triggered yet.  But it could happen.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Deadlocking sandbox?

[Pierre Asselin]

Suppose I have this in my modules file:

common  path/to/common/files
project_A   path/to/A   &common
project_B   path/to/B   &common

So far, so good.  I just have two projects, A and B, that share a
common subtree through the amperstand module "common".  Completely
normal.  But what if I add this?

gotcha  &project_A &project_B

A checked-out copy of "gotcha" will have two independent copies of the
"common" subtree.  My question:

Can I do a "cvs commit" from the top of "gotcha" ?

It seems that CVS will want to acquire two write locks on the "common"
tree in the repository and irremediably deadlock itself.  Is that
correct, or is CVS smart enough to recognize the first lock as its
own?

(I'm assuming that I'll be able to check out "gotcha" in the first
place, but that only seems to involve multiple *read* locks, so it
should be OK.)

To those who say "If you do that, you deserve whatever happens to
you" I reply "I agree".  But I have a case where such a sandbox would
actually be useful.  I would want to update from the top of "gotcha",
but not do anything that requires write locks.  Any advice?

Maybe I'll try it on a test repository.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: what's the strategy for managing mostly common code with a few project specific files?

[Pierre Asselin]

"HEILES,KATRINA (HP-Vancouver,ex1)" <[EMAIL PROTECTED]> writes:

> I have a set of code that is used by several projects.  Most of
> the code is common, but some are project specific/configuration
> files.  What's the best way to manage this?

Orgarnize each project so that the common files are segregated to a
single directory (or directory tree).  Then set up your modules file
like this:

common  path/to/the/common/subtree

proj_A  path/to/project_A &common
proj_B  path/to/project_b &common
...

When you check out module "proj_A", your sandbox will look like this:

proj_A/
files...
directories.../
more_files...
common/
the common subtree...


> I'm envisioning that each project will pull the common code from
> a labelled version of the trunk.

I generally put a big README file at the top of proj_A that says
something like this:

This project needs revision 1.4 of the common subtree.  Before
building, execute the command

$ cvs update -rREV_1_4 common

This README file is under revision control like the rest, and you
update it when you port to a higher rev of common/ .  Note that you
won't be able to commit changes to common/ from the proj_A sandbox,
which may be a good thing.

The common/ subtree had better be mature and stable, or you'll soon be
in trouble.  Also, it helps a lot if you can check out, build and
regression-test the common/ submodule by itself, without any files
from an enclosing projet.  CVS will let you check out common by
itself.



> Does it makes sense to have the project specific files specified
> differently in a modules file? I'd like projects to be able to pull
> from the same label but still have the ability to have a few files
> not come from that label.

I'm not sure what your first question means, but if you mix tags you
do so at your own risk.  You may find yourself unable to rebuild
proj_A because you forgot what exact combination you were using
under common/ .

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Log INFO

[Pierre Asselin]

"Alex Flores" <[EMAIL PROTECTED]> writes:

>How would I see the "cvs log" info for a file from one tagged version to
>the next.  I am trying to find bug defects fixed between loads.

$ cvs log -r: 

Also, you should *really* look at rcs2log , in the contrib directory,
or at cvs2cl.pl, at http://www.red-bean.com/cvs2cl/ .

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: tag aborted - cannot rename file

[Pierre Asselin]

Mike House <[EMAIL PROTECTED]> writes:

>cvs.exe [tag aborted]: cannot rename file
>c:/files/cvsroot/sys5/swim/man/,HELP_14.DOC,
>to c:/files/cvsroot/sys5/swim/man/HELP_14.DOC,v: File exists

>Ideas what I can look for?
>TIA, 
>Mike

Maybe variant spellings of HELP_14.DOC in your repository/sandbox/
CVS/Entries file, where the spelling differs in case only.
(Not likely, though.)

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Branching from Working Directory

[Pierre Asselin]

[EMAIL PROTECTED] writes:

>I would like to create a branch based on my current working directory.

>Well the problem is that the current working dir contains a lot of 
>locally modified files. I dont want them to be reflected in the main 
>trunk but only in the new branch.

I just answered that on comp.software.config-mgmt !  Anyway, no problem.

$ cvs tag my_branch_bp
$ cvs tag -b my_branch
$ cvs update -rmy_branch
$ cvs commit
hack, hack, hack...
$ cvs commit
hack, hack...

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Using Common files across multiple projects

[Pierre Asselin]

[EMAIL PROTECTED] (Thomas Frasher) writes:

>I'm trying to change the repository that we are using here.
>There are several projects that use some of the same files, headers and .cpp
>files.
>[...]
>I'm confused reading the documentation, it seems the ampersan commands are
>what is needed here, but I haven't been able to figure out how they work.

Amperstand modules are exactly what you need.


>Ideally I would like the checkout to get the files automatically, whether
>they are in a different repository (i.e. a different module) or whether they
>are local.

You can only mix files at the granularity of a directory.  You *can not*
have one directory populated by files from two different modules.
It's generally not too hard to structure your sources that way but if
you can't, you have to give up on CVS.

The simplest example would have a modules file looking like this:

common  path/to/common/files
project_1   path/to/top/of/project_1 &common
project_2   path/to/top/of/project_2 &common
...

When you check out project_1, you get:

project_1/
file
file
...
common/
common-file
common-file
...



> Also I need to put them back to the "home" repository when the
> changes are committed (all this without the need to commit me at
> the end of it).

Check.  When you commit project_1, the common/ subtree is committed
with it and people working on project_2 have to update.  Be careful that
changes to project_1/common not break project_2 !

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: branch-naming

[Pierre Asselin]

"Gianni Mariani" <[EMAIL PROTECTED]> writes:


>If you go to the repository and run this :
>You probably should back up your repository before doing this ...

>   rcs -nNEWTAG:OLDTAG (on every RCS file that contains OLDTAG)

>then this will create an alias (NEWTAG) for you.

If this works, you can save yourself some trouble by using cvs admin.
It will run the rcs command on all the files for you.

However, I suspect that the above command will only make NEWTAG
a synonym for the *tip* of branch OLDTAG.  If that's true, your only
recourse is to edit the ,v files !  Use a sed or perl script.
Double-backup that repository !

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS commitinfo trigger question

[Pierre Asselin]

"Bill Buie" <[EMAIL PROTECTED]> writes:

>I want to use a commitinfo trigger that will require a script of my =
>design to complete with zero status before permitting checkins to =
>certain branches.  The most obvious way to tell what branch a file is =
>being committed to would be with the cvs status subcommand, but I have =
>run into a catch.  The cvs commit subcommand locks the repository such =
>that the commitinfo script hangs when it tried to invoke the cvs status =
>subcommand.

You can use "cvs -n status" to get the info despite the lock.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: removing from rep.

[Pierre Asselin]

"Michael L. Hostbaek" <[EMAIL PROTECTED]> writes:

>What would happen, if I went and just did a cvs import
>some_module_that_exists in a devel dir ?

It would add your file tree to the tip of the vendor branch.  You will
then need to perform a merge on the trunk.  Something like

$ cd some/where/clean
$ cvs checkout -j -j 
$ cd 
fix conflicts
$ cvs commit

This is in the manual, under "Tracking sources".

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS Reporting

[Pierre Asselin]

[EMAIL PROTECTED] (Guy Scharf) writes:

>I need to produce a report of all files in a repository updated within 
>some date range.  I want the report to include any log comments on 
>changes made during that period.

http://www.red-bean.com/cvs2cl

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Changing branch name

[Pierre Asselin]

"Casey T. Zednick" <[EMAIL PROTECTED]> writes:

>I named a branch dev1-00, but I meant to name it dev0-11. I have already 
>merged the branch back into the trunk, but have a back up of the cvs-root 
>before I did the merge.

This is actually in the FAQ at www.cvshome.com .  From the top of
your sandbox,

$ cvs admin -ndev0-11:dev1-00
$ cvs tag -d dev1-00

You might want to cvs status a few files to make sure the dev0-11 is
there before you delete dev1-00.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: tagging problem

[Pierre Asselin]

Sangeetha Parthasarathy <[EMAIL PROTECTED]> writes:

The "tag" command works from a checked-out sandbox.  The "rtag"
command works from anywhere, but it requires

1) a date or existing tag, to know what revisions to tag
2) a tag name
3) a module name, to know what files to tag.

>cvs rtag -n -r versionNumberOne SManager
  ^^  ^^
  revision name   module name?

>But it won't work. I tried the same without the -n option. It still
>would not work.

The -n option only stops the program specified with -t in the
modules file from running --if there is one.  It has nothing to do
with your problem.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Administrative database file protection problem

[Pierre Asselin]

Dustin Cavanaugh <[EMAIL PROTECTED]> writes:

>My repository is on unix (Sun); the owner is "cvs" and the group is "cvs". 
>Whenever a user changes one of the Administrative database files, cvs 
>complains of Permission denied. Users (developers) are members of the cvs 
>group (though its not their primary group).

>I notice that when the database is rebuilt (either by commit or init), all 
>the database file protections are reset to -r--r--r--. I then su to cvs, do 
>a cvs init, and then manually reset the protections to -rw-rw-r--.

What about the directory permissions?  They should be group-rwx,
group cvs and preferably setgid (so that directories created under
them inherit the group ownership).

The file permissions will revert to r--r--r-- but that doesn't matter:
committing creates new files and unlinks the old.  What's required is
the write (and execute) permission to the *directories*.
--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: How can we maintain modules/directories/files between production and development environment using CVS

[Pierre Asselin]

"Datla, Raghav" <[EMAIL PROTECTED]> writes:

>Hi,
>  As a CVS administrator,  How can we maintain modules/directories/files
>when we have environments like production, stage and Development.
>I mean once Developers develop some code, test it and then I want to keep
>these files or code in the production cycle after testing is done.

One way is to do the development on the trunk, i.e. normal CVS ==
development tree.  When the code does to staging, that's a release
and it needs to be tagged.  At the same time, create a bugfix branch
starting at the staging tag.

$ cvs tag STAGE_4_0
$ cvs tag -b STAGE_4_0_bugfix

Then go off and check out a tree on the bugfix branch.  That's your
staging tree.  It is initially identical to what you just tagged on
the trunk, because the bugfix branch is empty.  If you find bugs,
they will be committed to the bugfix branch.

$ cvs checkout -rSTAGE_4_0_bugfix project
(Start qa work.)

When the code goes from staging to production, that's another
release and you tag it again (while still on the bugfix branch).
Then you go elsewhere and check out or export with the production
tag to get your production tree.

$ cvs tag -rPROD_4_0_0
$ cd /production/area
$ cvs export -rPROD_4_0_0 project

You may or may not want to start a production-bugfix branch off of
the production tag.  It's easier not to, and it wouldn't do you
any good if the production trees are exported.  Just do all your
bug fixes on the staging tree and re-tag, re-export to production.

Finally, merge the bugfix branch to the trunk periodically

$ cd /your/old/development/tree
$ cvs update -jSTAGE_4_0 -jPROD_4_0_0
(fix conflicts)
$ cvs commit
$ cvs tag -F -rPROD_4_0_0 STAGE_4_0_MERGED

The last command plants a "moving tag" (-F option) at the point you
just merged.  If you fix 3 more bugs and rachet up to PROD_4_0_3,
you can merge the new bugfixes from where you left off, then move the
tag.

$ cvs update -jSTAGE_4_0_MERGED -jPROD_4_0_3
(fix conflicts)
$ cvs commit
$ cvs tag -F -rPROD_4_0_3 STAGE_4_0_MERGED


IMPORTANT:
Resist the urge to merge cool new features from development to
staging and production.  Branches are much easier to handle if the
merges are unidirectional.  If the development tree is that good,
start over with STAGE_4_1.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs merge crash !!

[Pierre Asselin]

"Zanabria, Moises" <[EMAIL PROTECTED]> writes:

>That does mean that is no way to check a merge before I really want to
>merge??

Yes there is.  The merge isn't really over until you commit the
result.  The entire process looks like this:

1)  Check out a *clean* copy from the tip of the trunk.  After the
check-out, all the files in the local copy have a status of
"up to date".

2)  Do the merge, with "cvs update -jbranch_start -jbranch_end" .
This changes some of the files in the local copy, they now have
a status of "locally modified".  Some of them have conflict
markers and some don't;  nevertheless, they all appear as "locally
modified" *as if you had made the changes manually*.

3)  You fix the conflicts, if any, and make sure everything works.

Nothing is permanent yet, you still have a local copy with locally
modified files.  The go/no-go decision comes at the next step.

4a) You commit the result.  The changes go in the repository and the
local copy appears "up to date" again.
4b) You give up and delete the local copy.  It's as if nothing had
ever happened.

You can combine steps (1) and (2).  No matter.  The result of a merge
is a sandbox with locally modified files.  The fact that most of the
modifications were done by CVS is immaterial.
--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cannot commit ... sticky tags

[Pierre Asselin]

I missed the original, but the followup had enough quoted text...

>donald
>On Mon, Jan 07, 2002 at 05:12:44PM -0800, Schwenk, Jeanie wrote:
>> I'm using cvs 1.11 on hpux.
>> 
>> I tagged the Aug 21 release with the tag Release_Aug21_2001.  Just a plain
>> tag.  
>> 
>> While I was out for several weeks, the vendors who happen to be on the other
>> side of the world put a sticky tag on every file, including those I am
>> editing.

This doesn't make sense.  A tag can only be sticky in connection with
a sandbox.  Assuming you're not sharing sandboxes (say you're not
sharing sandboxes!) the only one who could have stuck your sandbox is
you.

One easy (too easy) way to get a sandbox with a sticky tag is to do

$ cvs checkout -rRelease_Aug21_2001 

or, from an already checked-out sandbox,

$ cvs update -rRelease_Aug21_2001

Presto, sticky tag (as witnessed by "cvs status").  What does this
mean?  That if you issue a cvs command from that sandbox, there is an
implied argument "-rRelease_Aug21_2001".  In particular, "cvs commit"
really meand "cvs commit -rRelease_Aug21_2001", and that's not
allowed.

The usual way out of this predicament is

$ cvs update -A

This is appropriate if you're done with Release_Aug21_2001 and you
want to keep developing on the trunk.  From your message, this is what
you want.  The update does two things:

1)  Removes the sticky tag *from your sandbox*;  "cvs commit" will
now mean plain "cvs commit".

2)  Merges the uncommitted changes you made in the sandbox with
whatever changes other people have committed to the trunk
since Release_Aug21_2001 while you weren't looking.  If nobody
else committed anything, this step will do nothing.  If there
have been intervening commits, the merge will do something
nontrivial and may generate conflicts, like a "cvs update"
from a normal sandbox.

3)  Mark your files as based on the tip of the trunk, when
before they were based on the revision numbers that correspond
to Release_Aug21_2001.  That is, your files are now "up to date".

OK, three things not two.  Check for conflicts and fix them.
You can now do a "cvs commit".


The unusual way out is to get on a branch.  This is appropriate if
your changes are *not* part of the mainline development but are
bugfixes to Release_Aug21_2001 only.  To branch,

$ cvs tag -b -rRelease_Aug21_2001_bugfix
$ cvs update -rRelease_Aug21_2001_bugfix

The first command just creates the branch.  The second command again
does two^Wthree things:

1)  Replaces your sticky tag of Release_Aug21_2001 by a new sticky
tag of Release_Aug21_2001_bugfix.  That is, "cvs commit" will
really mean "cvs commit -rRelease_Aug21_2001_bugfix" from now on.

2)  Merges the uncommitted changes you made in the sandbox with
whatever changes other people have committed on the branch.
Well, the branch is still empty, so this step does nothing.

3)  Marks your files as based on the tip of the branch.  You're
already on the tip, so nothing really happens.

Now you can commit.  The sticky tag doesn't get in the way, it just
puts your changes on the bugfix branch instead of the trunk.

After you commit, a "cvs update -A" gets you back to the trunk
(without the bug fixes).  This is another vacuous merge:  the changes
required to transform the tip of Release_Aug21_2001_bugfix into your
sandbox (empty, you just committed and didn't change anything), plus
the changes required to transform the tip of Release_Aug21_2001_bugfix
into the tip of the trunk (not empty, just a straightforward patch).
Result, you're up to date with the trunk  --and the sticky tag is gone.

The bug fixes are not on the trunk.  To get them, you merge the
branch.  Tag the tip of the branch and merge.

$ cvs tag -rRelease_Aug21_2001_bugfix Release_Aug21_2001_p01
$ cvs update -jRelease_Aug21_2001 -jRelease_Aug21_2001_p01

Fix conflicts, tests, etc.  Commit.  Ship Release_Aug21_2001_p01.
Optionally, plant a moving tag to remember what you merged.

$ cvs tag -F -rRelease_Aug21_2001_p01 Release_Aug21_2001_bugfix_MERGED

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cannot committ ... sticky tags

[Pierre Asselin]

"Schwenk, Jeanie" <[EMAIL PROTECTED]> writes:

>Thanks everyone for their responses but I need some additional
>clarification.  

>1)  I checked out all my files prior to the vendors putting the sticky tags
>on.

We all think the vendor did no such thing.


>So why are the sticky tags effecting me?

Either you ran "cvs update -r", or you did a
"cvs checkout -r".  In your first message, you
said you created the tag yourself.



>2)  removing the sticky tags (cvs update -A), does not effect the sticky
>tags in the repository just in my local copy?

There are no sticky tags in the repository, just tags.  There is a
sticky tag in your local copy if, after creating the tag in the
repository, you ran a "cvs update -r..." or "cvs checkout -r..." as
above.

A "sticky tag in a local copy" means that, if you run a cvs command
from that local copy, there is an implied "-r..." flag even if you
don't spefcify one on the command line.  Nothing more, nothing less.


>3)  Do I need to worry about any conflicts because there is a tag and a
>sticky tag with identical names?

There is only one tag, there can't be a conflict.  The tag is in the
repository, and it is visible from all local copies (try "cvs status
-v ").  In your local copy it is visible, and sticky  --implied
with every CVS command-- until you reset the stickyness with "cvs
update -A".


>It must not have given the vendors any
>warning but it just doesn't seem right to have a tag for release with the
>same name as a branch tag.

If there is a release tag and a branch tag, they must have different
names.  Run a "cvs status -v" on one your files and post the output.


>[...]
>Is it because commit verifies
>that the selected files are up to date with the current revision in the
>repository?  It doesn't make sense that it would be looking at the branch
>tags ... doesn't it compare with the trunk from where I originally checked
>out? 

Well, it depends:  if your local copy has no sticky tag, "cvs
commit" means just "cvs commit";  it checks against the tip of the
trunk and tells you to update if someone committed in front of you.
If you are up to date, your commit can finish and the contents of
your files become the new tip of the trunk.

If you have a sticky *branch* tag, "cvs commit" really means "cvs
commit -rBRANCH_TAG", so it checks against the tip of the branch
named by BRANCH_TAG.  If someone committed to the branch before
you did, you will be told to update.  Your "cvs update" will mean
"cvs update -rBRANCH_TAG" and you will be brought up to date with
the tip of the branch.  If you are up to date, your commit can finish
and, because of the implied "-rBRANCH_TAG",  the contents of your
files become the new tip of the branch.

If you have a sticky *release* tag (which is the pickle you're in),
then "cvs commit" means "cvs commit -rRELEASE_TAG", so it checks
that nobody committed to RELEASE_TAG while you weren't looking.
Of course nobody did, it's impossible.  Therefore your files are
up to date, and the commit proceeds to the next step...  which is
impossible.

Just do a "cvs update -A".  It will unstick your local copy and do
strictly nothing to the repository.  You'll like the result.
--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Any Real time examples of Branching, Please!!!

[Pierre Asselin]

"Datla, Raghav" <[EMAIL PROTECTED]> writes:

> Can anyone post me examples of branching in real time
>Dev-Stage-Production environment if you are using it. I will appreciate your
>help.

Mine is not a real-time environment, but it is a real environment :-)
In a nutshell, we promote to QA by tagging and starting a branch, and
we promote to production by tagging on the QA branch.

Development is on the trunk.  When the product has the features we
want, we tag the tip of the trunk for a QA-release and start hacking
on newer features.

QA starts a QA-bugfix branch off development's QA-release and starts
looking for bugs.  Bug fixes are commited to the QA-bugfix branch.
When it looks good, we tag the tip of QA-bugfix for a Production-release
but we keep fixing bugs on QA-bugfix.

Production exports the Production-release, builds it and runs it.

Bug reports from production are fixed on the QA-bugfix branch, a new
Production-release is tagged, and production takes it.  I suppose we
could start Production-bugfix branches off the Production-releases,
but we don't.

After a while tHe QA-fixes branch is merged to the trunk, so
Development has the bug fixes too.

Eventually, Development makes a new QA release.  A new QA-bugfix
branch is started and the old one is abandoned.


The mechanics of this has some nitty gritty.  Read the manual at
cvshome.org many times over.

---

General rules:
1)  Always know why you created a branch, and stick to its
purpose.  Example:  no new features on QA-bugfix.
2)  Merge in one direction only.  Example:  from QA-bugfix to the
trunk, never from the trunk to QA-bugfix (no new features).

Some organizations prefer to develop on branches, for example one
branch per feature.  When the feature is ready, merge with the trunk
and abandon the branch.  Then the trunk is used for integration more
than for development.  Releases to QA and Production can proceed as
above.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Is there anyway to not change a file when there are conflicts?

[Pierre Asselin]

"Stanton, Curt (NCI/IMS)" <[EMAIL PROTECTED]> writes:

>Here is the problem.  When CVS tries to merge a file and fails, it creates
>the two different versions of the code snippit seperated by the
>>>>>>=<<<<<.  Or somesymbols like that.  We find that to be hard to deal
>with most of the time.  We use another program called beyond compare to
>merge the two together.  We do this by getting rid of the file it crearted
>with those symbols and starting with the working copies modified file and
>the newest repo version.  My question is.  Is there any way to leave the
>file as is (in the not updated modified state) and mark it as having a
>conflict?  We still want it to merge the two if there weren't conflicts.
>Thanks in advance

-m 'COPY' in a .cvsignore file.  See the entry for 'cvsignore' in the
manual.  With that, "cvs update" should leave the conflicting copies
in your directiry --not sure how they will be called, I don't use that
feature much.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Forking off a remote public cvs. Howto merge the parallelldevelopment?

[Pierre Asselin]

Erik =?ISO-8859-1?Q?Sj=F6lund?= <[EMAIL PROTECTED]> writes:

>What possibilities are there to merge in new releases=20
>from the public cvs into our forked code in the future?

It's standard.  It can be difficult if a new distribution has a
radically reorganized file tree, but since they are also using CVS,
that's not too likely.


>Is there a way to do it by importing multiple times, maybe?

Exactly.

cvs import  VENDOR release_1

cvs checkout 
cvs commit
cvs commit
cvs commit
  ...

cvs import  VENDOR release_2

cvs update -jrelease_1 -jrelease_2
(fix conflicts)
cvs commit
cvs commit
cvs commit
  ...

cvs import  VENDOR release_3

cvs update -jrelease_2 -jrelease_3
(fix conflicts)
cvs commit
          ...

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Any Real time examples of Branching, Please!!!

[Pierre Asselin]

Wim Kerkhoff <[EMAIL PROTECTED]> writes:

>I'm interested in this well. We've recently moved to CVS, and I'm
>working on massively re-writing all our build scripts to support this.
>We use a scheme similiar to your Dev-Stage-Production environment. 

>How do you plan to handle versioning?  On the old system we used a 4
>digit build number for each distributed file as well as each
>distribution. Ie, periodically make a release (e.g. Build 3200), but
>regularly we release new versions of files via an update system within
>the product. So, if they do an update today a new foo.jar might get
>pulled in with a build number of 2783, or a new docs.pdf with a build
>number of 1087. This has come to mean nothing, especially as a component
>gets moved up from Dev to Stage, it takes over the build number of the
>previous build number in Stage plus 1.

This seems to be a distribution issue as much as a versioning
problem.

Where is the build number stored?  Directly in the file?  For source
files (foo.jar but not doc.pdf) you can embed a $Name$ keyword in a
comment, or even a displayable string.  If you do a cvs export of your
tree (also cvs checkout, I think), the keyword is expanded with
the tag you specified in the -r option.  So one solution to your
problem is to distribute your releases with cvs export.

The $Name$ keyword is not expanded during a "cvs update" of a
checked-out sandbox, even if you specify a tag.  I sometimes wish
it were, but it isn't.  If you "distribute" by having your customers
update a sandbox, I don't know how to embed meaningful numbers in
your files.  However, the sandbox owner can still see what he's got by
running cvs status, say, from the sandbox.

"cvs export" works fine for big releases, but it becomes clumsy to
use if you issue little patchoids all the time.  Updating a sandbox
works better for these informal releases, but they are closer to
the bleeding edge.

The .pdf files are more difficult.  If they are generated from text
sources, embed $Name$ in them, processing it if necessary.  I've done
that with LaTeX, for example.  If you use a WYSIWYG tool to edit the
pdfs you're stuck with the usual limitations CVS has with binary
files.  Can't do much.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cost of CVS...

[Pierre Asselin]

"vincent_choplin" <[EMAIL PROTECTED]> writes:

>I work in a small but still growing company and we're beginning to 
>need something like CVS...

>[...]  Is it worth hiring a temp. or consultant to install and 
>teach us?

A consultant may be a good idea in such circumstances.  The trick is
to find a good one.  Where are you?  In France?  Zut, c'est un peu loin.


>would we have to stop working while we put CVS up or can one of us do 
>it while the others go on with the developpement?

Nah, don't stop.  When CVS is ready, import what you have and save
the original into prehistory.zip .


>Is it really better to use linux on the server or are the winNT 
>versions good enough?

If you have a Linux box you probably have CVS already.  If you only
know Windows or only have Windows machines, try www.cvsnt.org , it
might be the path of least resistance.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs for dos

[Pierre Asselin]

"Schwenk, Jeanie" <[EMAIL PROTECTED]> writes:

>Anybody know if there is a way to access CVS using pserver from a Windows
>2000 command line?  

??  I thought the Windows distribution on cvshome.org *was* a
command-line version?

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Developer branches

[Pierre Asselin]

"Steve Ebersole" <[EMAIL PROTECTED]> writes:

>we have,
>as of yet, been unable to perform a successful build precisely because
>everyone is checking in code which does not compile with work of other
>developers.

They must be committing single files.  Tell them to commit wholesale
("cvs commit" from the top-level directory, no other arguments).
They will get a complaint from cvs that their sources aren't up to
date and that they should please run "cvs update" first.  Once they do
*that*, they have all the changes made by the others and they can
attempt a make --er, Ant-- to see if that builds.  If not, fix it and
commit only when it works.

So the sequence goes like this:

cvs commit  --darn, out of date
cvs update
Ant --darn, won't build
(fix conflicts)
Ant --success
cvs commit

On a hyperactive repository you might find yourself unable to keep
up:  somebody always commits another change while you're fixing
the mess after the update, so by the time your build completes
you're still out of date and have to update again, then fix, etc.

Frankly I doubt that a team of six can commit that often, but if
it happens you can start creating development branches.  One branch
per feature/subproject/whatever, not one branch per developer.
You want to keep *some* of that update-fixit madness, that's the
joy of concurrent development!  Seriously.  If you coordinate your
work just a little, the productivity boost is well worth the trouble.

If you do create development branches, you end up using the trunk for
integration.  You still have to make sure each branch builds cleanly
before attempting a merge, but you have a litle bit more flexibility:
you can put a branch on feature freeze without slowing the other
branches.  When a branch looks good (it had better build!) you can
merge it to the trunk and deal with conflicts (the integration work).


>...
>However, I don't think I really liked the idea of tags to perform this step
>because it is either adding responsibilities back on the developers to tag
>their code which is ready for build release (which the idea alone of them
>making that decision scares me) or back onto the release manager to
>determine what is eligible for release to build.

No, no.  When you tag from a sandbox, the tag is applied to the
versions *as of your last commit*.  If you've made changes without
committing them, the tag misses them --it has to, the changes aren't
in the repository.  I go back to your statement,

>we have, as of yet, been unable to perform a successful build

That is an anomaly.  Committed code should build, mostly.  It can
crash at run-time, but it should build.  How do you know it will
build?  because you built it before committing  --automated test,
no reason to skip it.


>We are a team of 6 and the
>project is huge, so adding any substantial additional work to one person's
>plate could be detrimental.

One of you has to play release manager.  It can be any one of you,
maybe even on a rotating basis, and with collegial input from the
whole team.

Once you reach a milestone, the release manager tags it and starts
a QA branch.  The QA branch is reserved for bug fixes (including
build failures, in extreme cases).  No new features.  When the QA
branch looks really good, you tag it and you ship what you just
tagged.  You also merge the bug fixes from the branch to the trunk.

And don't tag or branch individual files, you'll get a mess.  Tag
the whole project.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Partial checkout of an ampersand module

[Pierre Asselin]

"Bill Biessman" <[EMAIL PROTECTED]> writes:

>QUESTION:
>Is there a way to check out just one file from the tree below an ampersand
>module specifying the complete path?

>MORE DETAIL:
>
>I have a line in my modules file that looks like:
>whole_thing&part_one &part_two

First of all, you can already check out part_one by itself:
cvs checkout part_one

If you really want a single file from part_one, figure out what
part_one is.  There should be a line in the modules file that says
something like

part_onepath/to/part_one

You can then do
cvs checkout path/to/part_one/subdir/myfile

and you will get myfile, 4 directories deep.

>...
>look at the file for a while with a script, and then:
>cvs update -C -P -d whole_thing
>to get the rest of the files in the project.

Won't work.  Commit myfile from your deep sandbox and wipe out the
sandbox.  Then do a full checkout of whole_thing.  But if you're going
to check out whole_thing eventually, why not do it up front and keep
it checked out?

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: reverting changes

[Pierre Asselin]

Arcin Bozkurt <[EMAIL PROTECTED]> writes:


>The latest change to our repository was to commit some tens of files which 
>caused the code to break. I am trying to get back to the state a day ago and 
>commit it back to the repository effectively overriding the change made 
>(obviously this development had to be done on a branch but )

>I cannot use update -D yesterday, because the result is sticky. removing the 
>stickiness with -A takes me back to what the repository has.

>can we used -j with dates? Dates on -j only can be added when you have a 
>version/branch to point to.

Hmmm, if you're sure of the dates, you could do

$ cvs tag -D '2 days ago' tmp_pre_goof
$ cvs tag tmp_post_goof
$ cvs update -jtmp_post_goof -jtmp_pre_goof

When you're satisfied with the results, commit the sandbox and
delete the tmp_ tags.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Working directory & laptop?

[Pierre Asselin]

Eric Siegerman <[EMAIL PROTECTED]> writes:

>On Fri, Feb 08, 2002 at 09:55:45AM -0600, [EMAIL PROTECTED] wrote:
>> If I copy my working directory to my laptop, do some modifications, copy 
>> it back and do a commit, will I have any issues

>[pitfalls described]
>This is exactly the sort of confusion CVS can help with, so why
>not take advantage of that?  Instead of copying your desktop
>sandbox, do a fresh checkout directly onto the laptop; then you
>can commit those changes independently of your work on the
>desktop machine.  The standard CVS multiuser thing; it's just
>that both users happen to be you :-)

I'll second that and raise it:  install CVS on the laptop and
import the sources there.

Desktop:
cvs tag trip_bp : branch point
cvs tag -b -rtrip_bp trip   : branch
(cd somewhere else...)
cvs export -rtrip 
scp -r  you@yourlaptop:
rm -rf : the exported tree, that is

Laptop:
export CVSROOT=~/cvsroot
cvs init
cd 
cvs import -m'work on trip'  VENDOR start_of_trip
cd ..
rm -rf 
cvs checkout 
cd 
(take it away...)

When you come back,
Laptop:
cvs commit
cvs tag end_of_trip
cd
cvs rdiff -kk -rstart_of_trip -rend_of_trip  > trip.patch
scp trip.patch you@yourdesktop:trip.patch

Desktop:
cvs checkout -rtrip: new sandbox on the branch
cd 
patch -p2 < ~/trip.patch
(the patch should apply cleanly)
cvs commit
cvs tag trip_endpoint

Now you can go to a regular sandbox and merge your work:
cvs update -jtrip_bp -jtrip_endpoint

The only drawback is that your main repository sees only the start
and endpoints of what you did on your laptop, without the intermediate
stages.  Then again, do you want them?  Personally, I only use the
intermediate stages between milestones as fall-back positions in
case I mess up.  When things are solid, I stop caring about the
micro-history.  Just make sure your "trip" branch is in good shape
before you merge it.  If not, you should first polish it up on the
main computer, in the sandbox that's on the branch.

BTW, I'm assuming both computers use a unixoid OS, but all of this can
be done in Windows.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS Root Merge

[Pierre Asselin]

Dave <[EMAIL PROTECTED]> writes:

>We distribute our source to a remote location that does not have a network
>connection to our main CVS repository host. We tar the CVS root on tape and
>extract it on the remote host.

Strange.  Does the remote site have to see the detailed revision
history?  If not, I would just use cvs export to send them tarballs
of tagged releases.  They can import the tarballs into their own
independent CVS repository.  They can send you patches when they
make significant changes, and they can reimport and merge when you
make significant changes.

In other words, you pretend they are a privileged customer, they
pretend you are a responsive vendor.


>The problem is we need a way to capture the changes made during the
>installation in our main CVS root.

Your distribution method is unconventional, but they can still
generate patches and send them to you.

If you want tighter integration of the two sites, you're going to need
some sort of network...

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: trading files without ",v" suffix

[Pierre Asselin]

Claudio Klingler <[EMAIL PROTECTED]> writes:

>i have some files imported into my cvs repository. These files name's do and
>should not end with the ",v" suffix. Unfortunately cvs ignores this files.

This is not clear.  If you are trying to import files ending in ",v",
do a "cvs import -I! ...".  You'll get files ending in ",v,v" in your
repository, that's all.

To the list:
is "-I!" safe nowadays?  I used to type "-I! -I. -I.. -I.#*"
to avoid recursive trouble, but that was a long time ago.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: using files with .xls and .doc in CVS

[Pierre Asselin]

Rob Helmer <[EMAIL PROTECTED]> writes:

>Why do so many on the list poo-poo using binaries in CVS? 

Here's an excerpt from my cvswrappers:
*.bmp   -k 'b'
*.ico   -k 'b'
*.lib   -k 'b'

So I do put binaries in CVS, mostly when I don't have a better place
to put them.  They tend not to change much.  But .doc files?  yuk.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Hierarchical team integration in CVS

[Pierre Asselin]

"Earl Williams" <[EMAIL PROTECTED]> writes:

>Team A is responsible only for the internals package, and has written a
>harness project to help them test their classes in isolation.  Team B is
>responsible for all other classes in the app, and has written stub classes
>to stand in for Team A's work.  Both teams use the classes in the two
>utilities packages.

>How should these teams use CVS?

Adapt your tree structure.  Do *not* mix files from teams A and B in a
single directory, CVS won't handle that well.

The modules file can package things nicely for you, if you can live
with the resulting sandbox structure.

_utils  -d utils path/to/utilities
_team_A -d A path/to/team/A/files
_team_B -d B path/to/team/B/files

These aren't meant to be checked out.  If you did check out module
"_team_A", you would get team A's tree under a top-level directory
called "A" (from the -d option).  It wouldn't do you any good because
the shared utilities aren't there.

Next, create wrapper modules for each team.

Team_A  &_team_A &_utils
Team_B  &_team_B &_utils

If you check out "Team_A", you'll get a tree like this:

Team_A/
utils/
(the shared utilities tree)
A/
(team A's subtree)

and similarly for "Team_B".  These are complete trees, useable by the
teams, if they can stomach the layout.  Lean on them.

You'll also need to check out the joint project, so create a module
for that:

Fullpath/to/glue &_team_A &team_B &_utils

A checked-out sandbox would look like this:

Full/
(glue files)
utils/
(the shared utilities)
A/
(team A's subtree)
B/
(team B's subtree)

The "glue files" could include a top-level Makefile that knows what to
do with the subtrees, plus a README or two.  It could even be a big
sutbree in its own right.  Put in whatever you need to integrate the
two subprojects.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: problems with simple cvs update - changed file is not updated

[Pierre Asselin]

Heirler Stefan <[EMAIL PROTECTED]> writes:

>Scenario:

>cvs checkout foo.c

>... do nothing with foo.c, but others commit changes to foo.c

>cvs update foo.c

>no changes are retrieved

>This does not happen everytime doing an update but from time to time. Is
>there a known fact leading to duch a problem?


Just a wild guess, but are you using client-server?  is there a time
skew between the two machines?

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Hierarchical team integration in CVS

[Pierre Asselin]

"Earl Williams" <[EMAIL PROTECTED]> writes:

>Thanks very much for your detailed suggestions.  It seems that in order to
>use CVS, the directory structure of my project must be driven by short-term,
>division-of-labor-during-development concerns (Team A, Team B, Shared)
>rather than by the conceptual structure of the classes in my project.  Too
>bad.  I guess I need to learn more about Software Configuration Management.

??  The division into teams doesn't follow the logical structure?
Strange.  Anyway if the division of labor is short-term, just ignore
it.  Everybody check out the full Monty, just mind your own files.

Actually there is a way out, but I'm not sure I would recommend
it.  Lay out your full project's repository (and sandboxes) any
way you want.  Check out a full sandbox.  Then selectively create
a branch tag for the files that belong to team A.  Similarly, create
a branch tag for team B's files.

After that, if you do "cvs checkout -rteam_A_branch project", you
get a sandbox for team A.  If you "cvs checkout -rteam_B_branch project",
you get a sandbox for team B.  If you do a plain "cvs checkout project",
you get a full sandbox...  with none of the changes your teams have
made on their branches!

To get their work on the full project, the teams have to merge their
branches to the trunk periodically (or have an integration guy do it
for them).  The merges have to be done often, with floating tags to
keep track of what's already merged, etc.  When your division of labor
changes, stop using the branches and create new ones.

Like I said, I wouldn't recommend that approach, because of 1) the
perils of branching selectively;  2) the need for frequent merges and
floating tags;  3) the minimal advantage if gives you in hiding files
that you could just as well ignore.

The big, big weakness of CVS surfaces when you want to massively
reorganize your source tree.  CVS just isn't good at that.  It does
ok on static layout, subject to constraints that personally I can
live with, but it's hard to get the right layout on the first try!

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Newbie: howto share modules

[Pierre Asselin]

Syver Enstad <[EMAIL PROTECTED]> writes:

>I have a subproject in CVS (a directory in a module)
>where I want to have some other subprojects from CVS as
>subdirectories.

>Let's say we have:
>The following structure:
>(C++ is the root module)
>C++/Applications/MyApp 

>C++/Libraries/TheFirstLib
>C++/Libraries/TheSecondLib
>C++/Libraries/OtherLibs
>...

>Where I want to have
>C++/Applications/MyApp/TheFirstLib
>C++/Applications/MyApp/TheSecondLib

I'll assume you want to check out only MyApp and the two libraries.
Put something like this in your modules file:

TheFirstLib C++/Libraries/TheFirstLib
TheSecondLibC++/Libraries/TheSecondLib
...

Myapp   C++/Applications/MyApp &TheFirstLib &TheSecondLib

The first two are straightforward module entries.  You can check out
"TheFirstLib" and have it appear in ./TheFirstLib .  The third entry
is the application, and it implicitly checks out the two libraries as
submodules.  The sandbox looks like this:

./Myapp/
(Myapp files...)
TheFirstLib/
(1st library files...)
TheSecondLib/
(2nd library files...)

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: checking out to remote working directory

[Pierre Asselin]

Michael Sims <[EMAIL PROTECTED]> writes:

>At 09:15 PM 2/16/2002 -0500, Aden, David wrote:
>>[wants to check out on a remote NT machine]

>Install Cygwin on the NT server hosting the developer sandbox, 
>and setup the Cygwin sshd to run as a service.

I agree, but using Cygwin has security implications.  The distribution
explains them better than I can, but I *think* the sshd won't be
able to hide its address space from other NT processes, so your
sessions are vulnerable to snooping.

Mind you, someone would have to crack the NT box first, at which point
you've already lost that battle.  But there's no reason to open your
other accounts to the intruder, so *use a custom password for this
ssh account*.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Exclusions while tagging

[Pierre Asselin]

"Ben Baker" <[EMAIL PROTECTED]> writes:

>dist
>-non-media1
> -non-media1.1
>-non-media2
>-non-media3
>  -media   // Here's the media.  It's embedded within the dist tree
>-non-media4

>[ ... ]  However, it would also help our build process a
>great deal to be able to tag or rtag everything on dist except the media
>module.

Would it work to tag the whole shebang, then remove the tag from the
media files?

cd dist
cvs tag TEST
    cd ./-non-media-3/-media
cvs tag -d TEST

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Multiple modules inside a module hierarchy

[Pierre Asselin]

Bruno Mussard <[EMAIL PROTECTED]> writes:

>[ ... ]   I should like to set-up  the following hierarchy
>configuration for a new "top-level" module MY_PROJECT :

> MY_PROJECT/ ---> IP_BLOCKS/ ---> USART/
>  |   |
>  |-> USB_DEVICE/
>  |
>   -> ARM_CORE/

Nested amperstand modules?  I think they work.  If I understand
your diagram correctly,

USB_DEVICE  path/to/USB_DEVICE
USART   path/to/USART

IP_BLOCKS   path/to/IP_BLOCKS &USART &USB_DEVICE
ARM_COREpath/to/ARM_CORE

    MY_PROJECT  path/to/MY_PROJECT &ARM_CORE &IP_BLOCKS

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Any Real time examples of Branching, Please!!!

[Pierre Asselin]

Wim Kerkhoff <[EMAIL PROTECTED]> writes:

>In fact, I have taken the liberty of converting your post into a page on
>Wiki site that I have set up on practical release branching with CVS,
>over at:

>http://www.nyetwork.org/wiki/CVSReleaseManagement

Can't stop you, but you made a transcription error:

>>> QA starts a QA-bugfix branch off of development's QA branch, <<<

Should be "off of development's QA release", as in the usenet article.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: modules file

[Pierre Asselin]

Arcin Bozkurt - Archie <[EMAIL PROTECTED]> writes:


>The following are defined in modules file:

>CppAlgo-a CppAlgorithms
>SelAlgo-a SelAlgorithms

>Algorithms   &CppAlgo &SelAlgo
>algo Algorithms


>The last definition is not recognized.

Does the "Algorithms" module work as you want?  If so, try simply
algo&CppAlgo &SelAlgo

In the modules file, module definitions (the simpler ones, anyway)
have the form

modulename  path/to/the/top/of/the/module/tree

where the path is relative to $CVSROOT.  Then there are alias
definitions, amperstand modules, etc.

Your definition of "algo" sent cvs looking for a directory
$CVSROOT/Algorithms, *not* a module "Algorithms".

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: capturing test code in CVS

[Pierre Asselin]

Arcin Bozkurt - Archie <[EMAIL PROTECTED]> writes:

>What is the best way to capture test code for a module?

We had a thread on this not long ago.  All right, let's start from the
beginning:  what language?

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS - import to 1.1

[Pierre Asselin]

"Matthew Persico" <[EMAIL PROTECTED]> writes:

>Is there a way to cvs import into 1.1, not 1.1.1.1? Without the branch, the
>first lock and commit attempts will work as advertised.

>If I cannot do this, then I have to create an empty project and then write a
>script that will recurse a tree of code, doing cvs adds as appropriate and
>I'd rather not do that.

Doesn't "cvs add" recurse?  The procedure I remember goes like this:

mkdir emptydir
cd emptydir
cvs import -mdummy path/to/project/root DUMMY dummy
cd ..
rmdir emptydir

The import just creates an empty directory in the repository.  The
import message, vendor branch name and release tag are lost, there
aren't any files to hold them!  Add the new directory to your modules
file:

cvs checkout CVSROOT
cd CVSROOT
echo projectnamepath/to/project/root >> modules
cvs commit
cd ..
cvs release -d CVSROOT

Then,
cvs checkout projectname
cd projectname
: copy your source tree to where you are
: Hmmm... you may need to cvs add the directories first
:
find . -type d -print | xargs cvs add
:
: Darn!  I could have sworn that "cvs add" recursed once the
: directories were in, but I can't make it work on my
: (admittedly old) cvs.
: Here's a find incantation to add all the files.
:
find . -type d -name CVS -prune -o -type f -print | xargs cvs add
:
: all the files are added
cvs commit

The files will show up at revision 1.1.

The second "find" works by 1) excluding the CVS directories from the
search, and 2) listing all the files found elsewhere.  Works great in a
unixoid environment.  If your're stuck in Windows, well that's tough.

So it's work, but I wouldn't call a pair of one-liners a huge
scripting job.

If your files have spaces in their names, use
find ... -print0 | xargs -0 ...

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Newbie: nonsensical documentation

[Pierre Asselin]

<[EMAIL PROTECTED]> writes:

>I'm being forced by my supervisor to start using CVS, which I hate.

Does your supervisor --or anyone else in the group-- know any CVS?
The learning curve is steep if you have to do everything, but if
you're joining a group that already has everything set up, they
could just teach you cvs checkout, update and commit and you could
start hacking right away.

There used to be a CVSHELP(1) man page in the distribution way back
when.  I found it very useful.


>On page 29, one is instructed to do this:

>  $ cd $WDIR
>  $ cvs import -m "Imported sources" yoyodine/$RDIR yoyo start
>  $ cd ..

Yow, imports.  They're slamming you into it.  Ok, here's an overview
of how import works.

 *  Unpack or copy a clean source tree somewhere.
 *  cd to the top of the source tree.
 *  Run the import command.
 *  cd back up one directory and wipe out the source tree.


>I've done this (though, of course, I've changed "yoyodine/$RDIR" to
>"MyModule", and "yoyo" to $USER).

Good, so your source tree is now in CVS, rooted at directory
"MyModule" at the top of the repository.  The next step would have
been to put an entry in the modules file, but since your module is at
the top-level of the repository this is superfluous.

Now you want to cd to a clean directory to try out your import.


>Next, the instructions say to do
>try this:
>  $ cvs checkout yoyodine/$RDIR

Did they say to go to a clean directory first?

>so I try:
>  $ cvs -n checkout MyModule

That should work.  Er, why the "-n" option?  paranoia?

>but I get an error message:
>  cvs checkout: cannot chdir to MyModule: Not a directory
>  cvs checkout: ignoring module MyModule

It's the "-n" option.  CVS should create a top-level "MyModule"
directory, cd to it, and proceed to populate it with a copy of the
sources.  It didn't create the directory because of the -n option
and it should have known better than to try to cd into it.  If I'm
right, you found a bug!  Workaround: be bold.

$ cd
$ mkdir scratch
$ cd scratch
$ cvs checkout MyModule

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: File sharing

[Pierre Asselin]

"Ben Baker" <[EMAIL PROTECTED]> writes:

>We're in the process of converting from another source control system to =
>CVS and one of the things our previous system did that CVS does not is =
>file sharing.

If you mean what I think you mean, CVS can share files among modules,
but only at directory granularity.  In other words:  in a checked-out
sandbox, all the files in any one directory MUST come from a single
directory in the repository.

If your previous setup mixed the shared files, you have a reorganization
job to do before switching to CVS.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: dual repositories - please give me your thoughts

[Pierre Asselin]

"Daniels, David" <[EMAIL PROTECTED]> writes:

>Someone has proposed a CVS setup to me which I would very much like comments
>on. In this proposed system, there would be two CVS repositories. The first
>would be open to the development staff and would be for general use. The
>second would be an rsynced version of the first and would be for creating
>releases for testing or production.

I could see that if you have a slow link between two sites, but
otherwise why not use a single repository and eliminate the middleman?
"cvs export" works fine for releases.


>The second repository also would have
>the users who have access limited to the release manager for the project.
>The reasons I was given for a second repository include security and better
>manageability. Any thoughts?

Hmmm, you *might* be able to tune access more finely with a second
repository, but the argument isn't very convincing to me.  Any
specifics?

I don't think it can hurt much, when in doubt the development
repository is authoritative, but I don't see how it helps.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: sharing cvs root?

[Pierre Asselin]

"Hanser, Kevin" <[EMAIL PROTECTED]> writes:

>My boss seems to think it would be a good idea to share our CVS root so we
>can easily browse it.  I don't think this is a good idea... can anyone give
>me the pro's or con's of doing this?

If it's read-only, there wouldn't be much harm...


>We have our cvs repository located on a linux box, and are using winCVS to
>do our checkouts/updates/commits, etc.  He wants to be able to browse the
>cvsroot so he can see the modules  

If your modules file is well-maintained, There's "cvs checkout -c | more",
or "cvs checkout CVSROOT".  Recent versions of cvs have "cvs rlog",
which will tell you basically everything about a module, short of the
actual sources --you might want to pipe it into a script or two.

--
Pierre Asselin
Westminster, Colorado


-= Posted via Newsfeeds.Com, Uncensored Usenet News =-
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-==  Over 80,000 Newsgroups - 16 Different Servers! =-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Merging changes between branches

[Pierre Asselin]

In <[EMAIL PROTECTED]> "Yuval Rotem" <[EMAIL PROTECTED]> writes:

>We want to employ branches as a relatively isolated development environment,
>[ ... ]
>However, according to the docs, it seems that using CVS branches for this
>purpose isn't that trivial, at least in one respect: It should be possible
>to perform an update to merge changes from the main trunk into a branch (or
>vice versa). In CVS this requires me to remember when the last update was,
>and update with two -j flags, which is a bit awkward.

For multiple merges from branch to trunk, you plant a moving tag after
each merge.

$ : on the trunk
$ cvs update -jbranch_lasst_merge -jbranch_tip
$ cvs tag -F -rbranch_tip branch_last_merge

It's clumsy, but doable.  I'm not sure what to do for bidirectional
merges.  This could work:

--  On the branch, periodically merge *everything* from the trunk
since the branch started, planting a moving tag on the trunk
as above.  One moving tag per live branch.
--  To merge from branch to trunk, temporarily restore the trunk
to its state at branch creation time and merge the whole
branch.
$ cvs update -jHEAD -jbranch_starting_point
$ cvs update -jbranch
 or
$ cvs update -jbranch_starting_point -jbranch_tip
(Use the latter command if files get deleted on the
branch.)

It is essential that you merge all trunk changes to the branch,
otherwise you will lose code.  Hmmm, you may not need a moving tag
on the branch if you do it this way, since you always end up merging
the whole branch.  Caveat:  I've never tried it, and someone (Larry?)
said that CVS would get confused by two -j-j merges without an
intervening commit.  Not sure why, though.

Proposals to keep track of previous merges pop up on this newsgroup
from time to time.  Usually they entail extending the RCS grammar
(the "newphrase" production in the rcs(5) manpage).

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Problems using CVS transparently

[Pierre Asselin]

In <[EMAIL PROTECTED]> Sonam Chauhan <[EMAIL PROTECTED]> writes:

>PROBLEM #1: CVS usage must be transparent. This means no 'CVS'
>meta-directories are allowed [ ... ]

Give up now before you get an ulcer?

>SOLUTION #1: The way I solved this problem (I think) was by creating
>a parallel source controlled directory hard linked to the development
>hierarchy.

Does that work?  CVS has a way of ignoring files with link count
greater than 1.


>PROBLEM #2: How to add large numbers of files and directories to
>an existing cvs module.

I use find, on the fly.  If there are new directories,

$ find . -type d ! -name CVS -print | xargs cvs add

and ignore errors for directories that are already added.  For the files,

$ find . -type d -name CVS -prune -o -type f -print |\
> xargs cvs add

and also ignore double-add errors.

>I've also hit what seems to be a bug in CVS
>while trying the script the addition of some directories. cvs tells
>me they've already been added. For e.g. it says:
>cvs [add aborted]: there is a version in dir22/source already
>exists The 'dir22/source' directory also has a CVS sub-directory.
>But doing a cvs checkout does not create the dir22/source directory.
>Am I doing something wrong?

Are there any files in dir22/source, and if not, are you pruning empty
directories?  (the -P option).


>PROBLEM #3: How can I detect and commit changes to the development
>codebase when making a release?

cvs -nq update .

>As described in problem #2, new
>directories may be added or deleted arbitrarily by the development
>environment.

General impression:  you can have your development environment or you
can have CVS, and you can't have both.

Maybe you should treat your dev environment as a virtual vendor.
Export trees, not checkout, to use in development.  When ready,
import them back, not commit, into CVS, as if you were releasing
a tarball to yourself.  This is an extremely clumsy way to use CVS,
turning it into a glorified closet.  It also means that you develop
without the benefit of a source-controlled environment:  no cvs diff,
no cvs update, etc.

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Question on multiple repositories

[Pierre Asselin]

In  "Max" 
<[EMAIL PROTECTED]> writes:


> I'm brand new at the CVS game and have no senior resource available at
>work, so I'm hoping that I can get some help here.

> The specs I was handed at the office call for an open development
>repository and a secure QA/production repository.  Once developers finish
>their stuff, a baseline is made and the code is replicated to the QA
>repository.  This is the step where I'm having a problem.

Complicated.  Call it a formal release from dev to QA:   cvs export
from dev, cvs import in QA.  At the same time, dev creates a bugfix
branch and checks out a sandbox on it.  When QA fixes a bug, it
sends a patch to dev, who applies it to the bugfix sandbox, commits,
and merges back to the trunk.


> I'm hesitant to use "import" because (as I understand it) this command will
>club the previous versions under the same name (down the road).

That's what you have to do, though.  The QA people will just have to
learn how to do pre-import tags and post-import merges.  It's a lot more
trouble for them too, but those are the consequences of the rules
imposed on you.

Note that an import doesn't destroy previous imports.  It can break
the trunk until the post-import merge is finished, but past imports
are always available through their tags.

Faint glimmer of hope:  what do they mean by "secure QA"?  If
"secure" really means secure, you're in the import/export business
and that's that.  If "secure" only means "commits to QA tress are
restricted", then you *might* get away with commitinfo scripts that
reject commits by developers when on a QA branch.  Understand that
this is not "secure" at all, in that a developer determined to
break company rules can probably defeat the system.  It will only
prevent casual or inadvertent commits.  If acceptable, this would
be *much* better for all:  a single repository, dev releases to QA
simply by creating a tag, QA creates and manages the bugfix branch,
dev  merges directly from the branch to the trunk.

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Problems using CVS transparently

[Pierre Asselin]

In <[EMAIL PROTECTED]> Sonam Chauhan <[EMAIL PROTECTED]> writes:

>The proprietary IDE (something called 'webMethods B2B'), though
>lacking version control, has a inbuilt release mechanism. It zips
>up release directories in the working set. These ZIP files are then
>distributed to other servers. Hence we end up with CVS directories
>in 'live' servers. This takes us far far away from 'support land'
>and also may cause complications with the software's  internal
>functioning.

Can you intercept the .zip files and launder them?  My zip man page
says:

zip -d foo foo/tom/junk foo/harry/\* \*.o

will  remove  [from foo.zip] the  entry  foo/tom/junk,
all of the files that start with foo/harry/, and  all
of  the files  that  end  with .o (in any path).

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: FW: Symbolic tag information after a 'cvs release'

[Pierre Asselin]

In <[EMAIL PROTECTED]> Sonam Chauhan <[EMAIL PROTECTED]> writes:

>Sorry - Having never done *software* releases" with CVS myself, I misphrased my 
>query. What I really meant was 'cvs export'. In other words, we do a 'cvs 
>export' of a tagged branch as part of our release process. I wanted to capture 
>the tag name of the cvs-*exported* branch by processing a CVS variable in a 
>file. This does not seem possible.

There's the $Name$ keyword, but it won't give you the name of the
branch, just the name of the *release* you exported.  It makes no
difference if the release is on a branch or on the trunk.

Note:  you shouldn't export and ship with a branch tag, because you
won't know what you shipped.  You get the tip of the branch, and that
changes as the branch grows.

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: repository orgnization

[Pierre Asselin]

In <[EMAIL PROTECTED]> Joi Ellis <[EMAIL PROTECTED]> writes:

>I manage a CVS repository which I've used to store all of my projects
>for the past two years.  Recently my manager asked me to migrate this
>repository from my own workstation over to a company server so that
>everyone in our Engineering group can use it.

>I use JBuilder with my CVS repository, and the structure I have is simple:
>  
>  CVSROOT/module1
>  CVSROOT/module2
>  CVSROOT/module3
>  ...

Commit and release all your sandboxes and change that to

CVSROOT/leave_me_alone/module1
CVSROOT/leave_me_alone/module2
CVSROOT/leave_me_alone/module3
...

Add entries in your CVSROOT/modules to reflect the change:

module1 leave_me_alone/module1
module2 leave_me_alone/module2
...

You should be able to 'cvs checkout module1' exactly as before.


>The guys are migrating code from an ancient SourceSafe server into my
>repository, and they are building a tree-structure with their stuff:

>  CVSROOT/Engineering/Libs
>  CVSROOT/Engineering/APi
>  CVSROOT/Engineering/Firmware/i386
>  CVSROOT/Engineering/Firmware/strongarm

Ok, so now copy your CVSROOT/leave_me_alone/ tree to *their* CVSROOT,
add the entries in their modules file, and away you go.

The basic function of the modules file is to specify named subtrees
of the entire repository.

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Ampersand module question

[Pierre Asselin]

In <[EMAIL PROTECTED]> Martin Heinen <[EMAIL PROTECTED]> writes:

>On Tue, Apr 09, 2002 at 01:09:27PM +, Jay Glanville wrote:

>> [ ... ]
>> Now, is there a way to say that module amp1 should be included in module mod
>> and be placed in a directory called tools.  For example, when I do a
>> checkout of module mod, I get the following directories:
>>   mod
>>   mod/tools/amp1
>>   mod/amp2

>The -d option renames the working directory:

>| amp1 -d mod/tools/amp1 amp1
>| amp2 amp2
>| mod  &1 &2

I think it should be '-d tools/amp1', the 'mod/' is implied by the
amperstand mechanism.

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Ampersand module question

[Pierre Asselin]

In  "Jay Glanville" 
<[EMAIL PROTECTED]> writes:

>Thanks Martin.  It's a good start, but not all that I was looking for.  By
>using the "-d" option, what I'm doing is "front-loading" the naming
>architecture.  In other words, anytime I use module amp1, it will be under a
>directory tools

I create dummy modules for that purpose.  For example,

amp1path/to/amp1
amp2path/to/amp2
_amp1   -d tools/amp1   path/to/amp1
mod path/to/mod &_amp1 &2

The convention is that a module beginning with an underscore is not
meant to be checked out by itself --although nothing prevents you to.

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs