Google Answers Logo
View Question
 
Q: help on cvs ( Answered,   4 Comments )
Question  
Subject: help on cvs
Category: Computers > Software
Asked by: edwk-ga
List Price: $5.00
Posted: 19 Jun 2002 08:37 PDT
Expires: 26 Jun 2002 08:37 PDT
Question ID: 29189
Hello -
The cvs manual was pretty good for a beginner like me. But I was wondering if I
can get a little more help. I need to use CVS for the following:

I have a main directory called Software under which I right now have all my
files. so whenever I commit my changes, the software directory gets updated
with my new files or modified files.

But now, I want to create user home directories under the software where
users can have their own copies of the files form the main software branch.
And anytime the user commits the changes, only the files in his directory
gets updated and  not the main software branch files.

Can this be implemented?

Any suggestions?

Thanks.

Clarification of Question by edwk-ga on 19 Jun 2002 11:12 PDT
I wan to add on to my question as a clarification that, each user
should be able to modify the files and commit.  They get the copies of
files from the main software diretory. The commit should affect only
their diectory sturcture and not the files form the main software
tree.
only when a release is to be made, merge should be done and that
should make changes to the main software directory.
Until then, only the users workspace with all the files from the
software directory should be committed.
Thanks.
edwk-ga

Clarification of Question by edwk-ga on 20 Jun 2002 07:02 PDT
So, using tag nampespace, what I need to do, could be done ?

Clarification of Question by edwk-ga on 20 Jun 2002 07:30 PDT
I want to clarify my question properly.

      /--------developer 1
_____/______________
software main branch

The main software branch is used for releases. The developer 1 has his
own copy of all the files from the software branch. He modifies his
files and commits it into his own branch and not the main software
branch. This is becuase he wants to make sure that the changes he has
made is solid enough so that he can then merge it to the main software
release branch. Until he feels that it works properly, he needs to
commit only to his branch. Only when he is comfortable enough that
everything works properly, he merges it to the main release software
branch. The same is applicable for any developer. Can this be
implemented.

Thanks.
Answer  
Subject: Re: help on cvs
Answered By: eiffel-ga on 20 Jun 2002 12:56 PDT
 
Hi edwk,

Thanks for your clarification. You can indeed achieve what you want
using CVS. You don't even need to set up separate directories as you
intimated in your original question. Instead, every developer creates
a new branch but CVS keeps track of the different branches without
requiring a separate directory to be set up for each branch.

Suppose you have just released a version of your software, and several
developers now wish to work on separate new features. Each developer
wants to focus just on her own work, without worrying about what the
other developers are doing. When each developer commits, the commit is
to her own branch and the main branch is not affected. Eventually,
when each developer has finished her new feature, she will merge it
back into the main branch. Finally, when all developers have merged
back their branches, the next version is ready for testing. After the
new version has been released, the whole process can start again.

Here's how to do it, assuming you have given a module name to your
project. Much of this information is drawn from the CVS FAQ maintained
by David G Grubbs:
http://mssls7.mssl.ucl.ac.uk/sw/help/cvs/cvs-faq/cvsfaq0.html

1. After a release, tag the module so that you can always refer to
this point again. The 'branch_point_tag' could be a name such as 'V1'
for the version 1 release:

cvs rtag <branch_point_tag> module

2.Each developer defines a new branch by attaching a branch tag to the
release version. The 'branch_tag' could be the 'branch_point_tag'
followed by the developer's initials, for example 'V1_SW':

cvs rtag -b -r <branch_point_tag> <branch_tag> <module>

3.Each developer checks out her private copy of her private branch:

cvs checkout -r <branch_tag> module

Because the '-r' parameter makes the branch_tag 'sticky', when the
developer commits it will be to her own branch.

4.When a developer is ready to do so, she merges her work back into
the main branch:

cvs update -j <branch_tag>

5.After resolving any conflicts, she commits to the main branch:

cvs commit

Unfortunately, it's not always quite as simple as that, and there are
some 'gotchas' to consider. The following parts of the CVS FAQ give
more detailed instructions and guidance:

How do I create and checkout a branch?
http://mssls7.mssl.ucl.ac.uk/sw/help/cvs/cvs-fq/cvsfaq28.html#4C.3

How do I merge a whole branch back into the trunk?
http://mssls7.mssl.ucl.ac.uk/sw/help/cvs/cvs-faq/cvsfaq28.html#4C.6

I have described how you can use CVS to enable your developers to
commit to private branches until they are ready to merge back into the
main branch prior to a release. However I feel compelled to add that
most CVS users would prefer to merge early and often so that
integration problems come to light sooner rather than later. Of course
it's your call here.


Additional resources:

A Real Beginner's Guide to CVS, by De Clarke
http://www.ucolick.org/~de/CVSbeginner.html

'Branching and merging' (from the CVS manual by Per Cederqvist et al)
http://www.loria.fr/~molli/cvs/doc/cvs_5.html

Use of CVS Branching for Collaborative Code Development (from Software
Development Conventions for Tech-X Projects)
http://www.txcorp.com/codeconventions/BranchRelease.html


Google search used:

cvs branch merge
://www.google.com/search?q=cvs+branch+merge


Good luck! CVS is not the easiest tool to learn, but it's very
powerful.

Regards,
eiffel-ga

Clarification of Answer by eiffel-ga on 20 Jun 2002 13:07 PDT
There is a typo in one of the links above. It should read as follows:

How do I create and checkout a branch? 
http://mssls7.mssl.ucl.ac.uk/sw/help/cvs/cvs-faq/cvsfaq28.html#4C.3 

Sorry for any inconvenience!

Request for Answer Clarification by edwk-ga on 21 Jun 2002 06:45 PDT
Hello eiffel
Thanks for your answer. Looks like this will work. I shall try and see. 
Thanks a lot.

edwk

Clarification of Answer by eiffel-ga on 21 Jun 2002 07:00 PDT
OK, you're welcome edwk.

Request for Answer Clarification by edwk-ga on 21 Jun 2002 07:04 PDT
Hello eiffel
Thanks for answering my question regarding CVS branching. Is there a
way to find the tag name. I see the tag command to tag a module. My
repository name is software under which I have all the files which is
used for releasing.How do I see what is the tage name inroder to try
out your explanation for my question regarding commiting and merging?

Thanks.
edwk

Request for Answer Clarification by edwk-ga on 21 Jun 2002 07:30 PDT
Hello Eiffel -
In your explanation, you have mentioned:
3.Each developer checks out her private copy of her private branch: 
 
cvs checkout -r <branch_tag> module 

this looks like, there is already a module named "module" in the main
release branch since checkout of that "module" is done above. In my
case, software is the only repository name under which I currently
have all the files. SO whenever a commit is performed, the software
repository gets updated. I want to change this by having my home
directory where I will update all the files form the repository and
commit to my home directory only until a release is to be made to the
software repository by doing a merge.

Hope this is clear.
Thanks.

Clarification of Answer by eiffel-ga on 21 Jun 2002 08:21 PDT
Modules are just a convenient way to refer to one or a group of CVS
paths.

You choose your module name, and enter its definition into the modules
file. Instructions are in the CVS manual here:
http://www.loria.fr/~molli/cvs/doc/cvs_18.html#SEC153

If you don't want to bother with module names, you can just use
pathnames relative to $CVSROOT instead.

You don't need to 'find' a tag name; you just make one up. For
example, you could systematically use version numbers and developer
initials as I showed in the main answer. You tell CVS about your tag
(e.g. the cvs rtag commands in the main answer) and CVS associates a
particular version of your files with that tag. By referring to that
tag again, you can refer back to that specific version (for example to
create a new branch from that point).

You can read about tags in the CVS manual here:
http://www.loria.fr/~molli/cvs/doc/cvs_4.html#SEC47

Clarification of Answer by eiffel-ga on 23 Jun 2002 07:39 PDT
Hi edwk,

The solution I offered in my answer addresses the situation that you
described in your final "question clarification". By having each
developer work on a separate branch, they can commit as often as they
like to that branch without affecting the "head" branch. Prior to a
new release, their changes can be merged into the head branch. But all
branches are committed to the CVS server.

In one of your requests for answer clarification, you refer to keeping
intermediate developer versions in the developer's "home directory".
You don't need to do this, because CVS keeps each branch logically
independent. So each developer can have a checked-out copy of their
private branch in their "home directory", even though all the private
branches are committed to the same physical directory under $CVSROOT
on the CVS server.

If you still want to make intermediate commits to a local directory,
then I echo the comments posted by others who suggested that CVS is
not well-suited to this mode of operation.

Request for Answer Clarification by edwk-ga on 25 Jun 2002 06:46 PDT
Hi Eiffel -
My question was, if each individual user can commit their changes only
in their branch rather than affecting the main CVSROOT (as per your
last explanation its not clear) Only when a release is to made, the
changes are merged to the main CVSROOT. Is this possible?

Thanks.

Clarification of Answer by eiffel-ga on 25 Jun 2002 07:49 PDT
> My question was, if each individual user can commit
> their changes only in their branch

Absolutely, yes. By using the "sticky" flag when the developer checks
out her private copy of her branch, subsequent commits will
automatically go to that same branch only.

> rather than affecting the main CVSROOT

If by this you mean "rather than affecting the main branch" then again
the answer is "absolutely, yes".

But if by this you mean "without the CVS server modifying any
directories below the one identified by the $CVSROOT environment
variable", then the answer is "no" (because CVS stores all the
branches under $CVSROOT). However, nothing in your question or
clarifications suggests any reason why this would be problematic.

> Only when a release is to made, the changes are
> merged to the main CVSROOT. Is this possible?

If by this you mean "Only when a release is to be made, the changes
are merged to the main branch...", then again the answer is
"absolutely, yes".

The clarification that you posted on 20 Jun 07:30 PDT describes a
common requirement for distributed development, and one that CVS
handles well, as described in the main answer.

If there is a reason why you do not find that solution acceptable,
please explain what you perceive the problem to be, and I'll try to
help.
Comments  
Subject: Re: help on cvs
From: lexi-ga on 19 Jun 2002 09:42 PDT
 
Are you sure you don't just want to give your new users readonly
access to the repository?  They could set up their own workspaces
where they pull in changes from your main branch and make their own
modifications, but would not be able to check anything in.
Subject: Re: help on cvs
From: netcrazy-ga on 19 Jun 2002 10:51 PDT
 
Hi,

Check out this page (
http://mssls7.mssl.ucl.ac.uk/sw/help/cvs/cvs-faq/cvsfaq27.html ). It
has several FAQs which can help you out.

Thanks
netcrazy
Subject: Re: help on cvs
From: lnixon-ga on 19 Jun 2002 15:47 PDT
 
If I understand you correctly, what you would really like is for each
user to have a private repository, in which they could work on their
files in a sequence of edit-commit cycles. When they are satisfied
with their changes they commit them
to the master repository, upon which the changes become visible to the
other users. Correct?

This kind of hierarchy of repositories can't easily be set up using
CVS. Sorry.

You might want to have a look at the arch project, which has exactly
this
approach to version control:

http://www.regexps.com/arch.html
Subject: Re: help on cvs
From: qotile-ga on 19 Jun 2002 16:25 PDT
 
This is just about impossible to do with CVS since branches are build
on top of the tag namespace, not directories.  However, you may want
to look into using Perforce (http://www.perforce.com) where branches
are built on top of the directory namespace.  (Perforce is very solid,
although it's not free...)

Important Disclaimer: Answers and comments provided on Google Answers are general information, and are not intended to substitute for informed professional medical, psychiatric, psychological, tax, legal, investment, accounting, or other professional advice. Google does not endorse, and expressly disclaims liability for any product, manufacturer, distributor, service or service provider mentioned or any opinion expressed in answers or comments. Please read carefully the Google Answers Terms of Service.

If you feel that you have found inappropriate content, please let us know by emailing us at answers-support@google.com with the question ID listed above. Thank you.
Search Google Answers for
Google Answers  


Google Home - Answers FAQ - Terms of Service - Privacy Policy