"Cameron, Steve" wrote:
>
> [smc] [snip]
> [smc] [..regarding "cvs update -j rev1 -j rev2 myfile.c" ]
> > >
> > > rev1 and rev2 can be arbitrary revisions. (Well, with the
> > > restriction
> > > that they must already be in the same repository...which is
> > > the main difference I see from the proposed "cvs patch".
> >
> > That, plus that 'cvs patch' permits any tool to create patch files.
> > I could, for example, get a diff from another source code system, or from
> > another user elsewhere. Might not even be based on the same file.
> [smc] Hmm it seems to me then, just use patch. I'm no expert on
> patch though, perhaps it has inadequacies that make it unsuitable.
> [snip]
Simply that it won't mark conflicts the same way that CVS marks conflicts.
> > (Incidentally, does update -j -j work if the two revisions are not on
> > related
> > branches?
> [smc] the two revisions may be any arbitrary revisions, just as
> you
> can feed any arbitrary patch into the patch program, doesn't mean it
> will
> work nicely.
>
> > What if there is a conflict between the two revisions, as well as a
> > conflict in
> > your own code in applying this? (all three versions do different things to
> > one
> > area).) [smc] There can't be a "conflict between the two revisions."
> > You
> have to have at least 3 revisions before a conflict is possible...so
> I'm not
> sure what you mean.
>
> When you do "cvs update -j rev1 -j rev2 myfile.c", it is very much
> like
> (identical to?) doing
>
> diff -c myfile.c.rev1 myfile.c.rev2 | patch myfile.c
> >
> > [smc] [snip]
Ok, then perhaps I misunderstood the effect of the two j's.
I was thinking of two pieces of code, on two different branches. Both made
different changes to the same piece of code. The 'cvs update -j -j' would (I
had thought) figure out the base version, apply the -j rev1 patch, apply the
-j rev2 patch, mark the conflict, and then let you sort it out; trying to then
use patch to apply another modification that also alters that area would give
you a three point conflict.
I haven't had to use two j's yet (haven't re-used a branch after committing to
trunk, haven't wanted to diff across two different branches), so I didn't know
it's behavior.
> > Now, if 'branch2' (the new) is a descendant of 'branch1' (the old), and I
> > want
> > a script to automatically go up one level of branching, how do I do that?
> [smc] Sorry, I don't know what you mean by "go up one level of
> branching"
Assume something like the following:
cvs update -A # back to trunk, like '/'
cvs tag base-branch1
cvs tag -b branch1
cvs update -r branch1 # on branch1, like '/branch1'
<edits, commits, etc>
cvs tag base-nestedBranch
cvs tag -b nestedBranch
cvs update -r nestedBranch # on nestedBranch, like '/branch/nestedBranch'
<edits, commits, etc>
cvs tag base-deepBranch
cvs tag -b deepBranch
cvs update -r deepBranch # now like '/branch/nestedBranch/deepBranch'
<...>
Now, how do I now say "Ok, go back to 'nestedBranch'"? In other words, at this
point I can say
cvs update -A # go up 3 layers, like 'cd /'
but what I want is the equivalent of 'cd ..'.
> > How do I say 'Look in CVS/Tag, find the place where this branch came from,
> > and go to that branch or trunk'?
> [smc] "place where this branch came from?" I think you mean what
> branch
> did this branch branch off of? Which might be different on a
> file-by-file basis...
> (a pathological case, to be sure.) I don't think you can do that.
> Or know why
> you'd want to... what are you trying to accomplish?
The same thing I'm trying to accomplish by using branches in the first place
-- putting my experimental code out of the way until it either works
(tagname-committedToTrunk) or is abandoned (tagname-abandoned)
(hmm, gotta change my naming from 'committedToTrunk' to 'committedToParent'.)
And, so what if it is different on a file by file bases? Revision numbers and
branch numbers already differ on a file by file basis. If necessary, why not
look in each file separately? Or, as I suspect (now, not when I started this
last week) that CVS doesn't write enough information into the RCS files to
track this if no change is made to the file in question, why not have CVS
(server, probably) make two passes, the first to determine what the branching
order is, and what the parent branch is, and then use that?
Or, since this isn't the first time that the RCS file format, and not storing
tag information for branches when no change is made has caused problems, why
not have every branch (excluding the vendor branch ?) make a dummy diff when
created?
> > And, my first question is still there: if I have some files that are
> > modified,
> > and I do a 'cvs update -r new-revision', I'll move over to new revision;
> > if
> > files are modified, then any changes will get merged in.
> >
> > How do I say 'only permit this update -r if my (modified) files are
> > current for
> > the new location? (no merge needed)
> [smc] If I understand correctly...
>
> You are working away on some branch, branchA, say, and you want to
> start working on branchB, but you don't want to blow away mods you
> have
> made (but not committed) to your branchA sandbox... is that it?
More like:
I have a module checked out. I'm not the developer. My environment is slightly
different than the developer's.
I have had to make a minor change (Makefile and PB.project, for example). Or,
lets say I don't need as much debugging output as the main developer, and have
commented out some of the programmer's logging. Or added some of my own.
I want to update and get the new stuff, but I only want that to happen if no
merge is needed (because nothing that I've had to modify is out of date).
Or, lets say that I'm not even an objective-C developer. I'm just told 'use
the -j sandraModels' flag to check out a version that uses EOModeler files for
databases on deployment machine sandra instead of the default using databases
on development machine sara. How does the programmer say 'and use flag -X to
force this to work only if there isn't a conflict, even if the database models
do get updated'?
> Can't do it, not that way. (I can't think of a way, at least)
> Hmm. you could do "cvs -nq update" ...
That will work at detecting when a file has been modified both by me and by
CVS. And, it can be scripted (perhaps a '.cvsDoNotUpdateFiles' file, like
.cvsignore).
What about the other case (permit this if no conflict during merge,
prohibit if conflict during merge)?
Michael
