info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cvs add question


From: John Lash
Subject: Re: cvs add question
Date: Sat, 14 Jul 2001 08:56:09 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2+) Gecko/20010713

Eric & Rajesh,

thanks for the reply. Here are some of my reasons for abusing CVS ;-).

What I'd like to be able to do is pull a branch off of the trunk, or another
branch, at some stable point (MYLABEL) and start working. I may be on this
branch for a while and would like to keep up with the trunk but always at
various well defined (stable) points. To do this, I now need to update all of
the files I branched. Doing this creates actual deltas on those files and starts
to confuse me on which files I have actually modified as part of my work. The
first couple of iterations of this aren't too bad but after a week or so it
seems quite unwieldy.

What I do, is extract the labeled version of the files. Then I extract the files
on my branch on top of the first set of files. When I edit a file for the first
time, I must put it on the branch (sort of a checkout'ish type of command). If I
want to know which files I've touched, I can list the files on the branch
knowing that only my mods are there.

Moving my branch to a new stable spot becomes fairly simple, I re-extract the
files using that new label, then do an update of my files relative to that 
label.

This is almost the behaviour of the "-f" option on update and checkout. They
extract the branched files, and then any files not on the branch are pulled from
  HEAD. What I'm attempting to do is rather like having a -f MYLABEL argument.
Actually, I've thought about taking a crack at that sort of change but wanted to
try this stuff out for a while before I wade into that.

As I described in the original email, the only place I have gotten into trouble
is when I want to add a new file.

I hadn't thought of using the -A option on update. I assume it won't mess with
locally modified files. That might get me out of the business of dinking the Tag
file. The drawback would be that it will do an update to HEAD to insert the
file. It's possible that I might be branched off another branch, but then I
suppose I could just branch the file as for a checkout.

Anyway, that's the stuff I've been thinking of. I'm relatively new to CVS (ex
clearcase user, tell the truth, it shows, doesn't it?)  I'm currently fighting
the "Hey, lets get Clearcase! It does everything, cuz there's a big company
charging money for it, right?" battle at work. I've got no particular axe to
grind w.r.t. Clearcase and I don't want to clog the mailing list with a
flamefest on the relative merits of x over y.

If anybody'd be interested in relatng the philosophy/history behind CVS's
branching mechanism, I'd be quite interested. I assume that there are reasons
for doing it that way. How do others handle it.

regards
--john



Eric Siegerman wrote:
> On Thu, Jul 12, 2001 at 07:18:13PM -0500, John Lash wrote:
>
>>I have extracted a directory from CVS using a non-branch label off the trunk 
of
>>the source tree.
>>        cvs checkout -r MYLABEL foo
>>I want to add a file in that directory but I want to add it on a branch
>>(MYBRANCH).
>>
>
> The usual way (and by far the best) is to branch the entire
> project, not just the one file:
>    cvs tag -b -rMYLABEL MYBRANCH
>
> Then put your sandbox "onto the branch":
>    cvs update -rMYBRANCH
>
> Then add and commit the file as usual:
>    cvs add newfile.C
>    cvs commit
>
> Finally, once you're done working on the branch, go back to the
> mainline:
>    cvs update -A
>
> Why is this better?  Because:
>   - If you later need to make more changes on the same branch,
>     you won't have to figure out whether you already branched the
>     file in question (you'll know it's been done).  You'll be able
>     to just make your changes and commit them, without the constant
>     distraction of keeping the revision-control stuff straight.
>   - When it comes time to merge the branch back into the
>     mainline, CVS will be able to help you more effectively.
>
>
>>I eventually got the file added to the branch but had to temporarily modify 
the
>>CVS/Tag file to make it contain "TMYBRANCH",
>>
>
> Which is one of things the "cvs update -rMYBRANCH" step does.
>
>
>>then flip it back to the original
>>"NMYLABEL".
>>
>
> Which is one of the things "cvs update -A" does.
>
>
>>yuck.
>>
>
> Indeed!
>
>
>>I'm curious if there is a better/safer/saner way to do it? Also, are there
>>negative side effects of using this trick.
>>
>
> See above, on both counts :-)
>
>
>>And finally, has anybody considered
>>allowing use of the -r option on the add command?
>>
>
> I'd argue against it.  You're trying to use CVS in a rather
> nonstandard and ugly way.  I'd prefer to encourage you to use it
> as it was intended to be used.
>
>
>>Strangely enough, there are reasons for doing all this which I can explain if
>>anybody cares.
>>
>
> If they're compelling reasons not to do as I've suggested, an
> explanation might help us to come up with a (perhaps still
> nonstandard, but less ugly) way to do what you need.
>
> --
>
> |  | /\
> |-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
> |  |  /
> With sufficient thrust, pigs fly just fine. However, this is not
> necessarily a good idea.
>    - RFC 1925 (quoting an unnamed source)
>
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs
>
>
>


--
John Lash       address@hidden







reply via email to

[Prev in Thread] Current Thread [Next in Thread]