(subject has been renamed slightly.)
"Cameron, Steve" wrote:
> Tobias Weingartner wrote:
> > I wrote
> > > How about this compromise: A CVS command to walk the local sandbox, find
> > > all the patch reject files, and mark conflicts properly? (With an option
> > to
> > > clean up the patch output files afterwards, perhaps smarts or a switch
> > to
> > > remove those patch outputs that were successfully dealt with
> > already/prior
> > > run/manually, etc?)
> >
> > Nope, this would be better suited in the "patch" binary itself. It is
> > already
> > "walking the tree", since it is going after the patch file. It could have
> > a
> > "cvs mode" of sorts. Not really the way the patch maintainers are likely
> > to
> > do it though...
It also isn't patch's place to update's CVS's data.
The files in CVS/ are owned by cvs; they are the data structures that CVS uses.
It is not anyone else's place to modify them.
Or do you believe that they never change? (they have changed once, right?)
> > > Or a CVS command to take diff files as input and apply the changes,
> > marking
> > > conflicts appropriately?
> >
> > Hmm, this one has some merit. We do have a "diff" tool within CVS, so why
> > not a "patch" tool. I'd veto it on the grounds of bloat, patch is by no
> > means
> > a "small" tool. On the other hand, I'd see it as a way to round out the
> > support that CVS would/could have for diff/patch...
Didn't CVS use to call rcs to do things? So now it calls patch, and examines
the public output from it.
> Also, you can kind of already do this.
>
> e.g. cvs update -j rev1 -j rev2 file_to_be_patched
>
> And of course this can extend to the entire repository at
> one shot.
>
> 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.
With a 'patch ... ; cvs clean-patch' setup, I can use a patch file that
has patch asking me 'what file to modify?', and then get conflict marks made.
With 'cvs patch', I have to make sure that the patch file actually refers to
files in the repository.
With 'cvs update -j -j', the two versions must already be in the repository.
(Incidentally, does update -j -j work if the two revisions are not on related
branches?
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).)
> > > Tell me the CVS command to "Merge this up one level".
> > >
> > > "cvs update -A" will get me back to the trunk from any level down of
> > > branching, assuming that nothing is modified.
> > > What is the flag to update to only go up one level of branching?
> > > What is the command to move elsewhere on the tree only if it won't cause
> > a
> > > conflict, or if it won't cause a merge?
>
> [smc] Or you can use "cvs update"
>
> e.g. suppose I have branch1, and branch2. I want myfile.c to be the
> same
> on branch1 as it is on branch2.
>
> rm myfile.c
> cvs update -r branch1 myfile.c
> cvs update -j branch1 -j branch2 myfile.c
> # note, you are pretty much guaranteed no conflicts here.
> cvs commit -m 'now equals branch2 revision.' myfile.c
>
> The fact that the trunk is anonymous may give you
> some trouble here, if you're working on the trunk,
> but regular tags can help out in that case.
>
> However, the thing is most people usually do _not_ want
> to make one branch _equal_ to another, they want the
> changes from one branch merged in to another branch.
Thank you.
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?
cvs update -A removes all branches, back to the trunk.
How do I say 'Look in CVS/Tag, find the place where this branch came from,
and go to that branch or trunk'?
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)
How do I say 'only permit this update -r if no conflict will result from the
merge'?
Michael
