Tobias Weingartner wrote:
> On Tuesday, March 7, Michael Gersten wrote:
[smc] [..snip..]
> > The current CVS update/commit, without built-in support for flying fish,
> > does not support that middle step: track changes to it.
>
> Ahh, I think you need to look into tags. One place I worked, not
> necessarily
> the best way of doing it, had a number of tags (not branches), which were
> used
> to help in this regard. The head of any branch where development was
> going
> on, there was a tag which was the tag used to build off of.
[smc] We do something very similar here, works pretty well for us.
[..snip..]
> > 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...
>
>
> > 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...
>
[smc] Hmmm. Doesn't CVS already contain a significant
part of "patch", or something very like it, in order to do merging?
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".
[smc] [..snip..]
> > > Ok, what is to prevent you from making a diff of your current changes
> (to
> > > save them), checkout/update on the branch, merge that to the trunk
> >
> > 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?
>
> You can do diffs between pretty much any two revisions of a file. So, if
> you
> have something that you commited on a branch, between two revisions, and
> you
> need to move this to the trunk, you can take a diff, and use "patch" to
> help
> you in the "transplant" of the code. Of course, your milage will vary,
> depending on how close the two codebases really are...
[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.
However, if this is what you want you can do it:
cvs co -r branch1 entire_repository
cd entire_repository
cvs rtag -r branch2 branch2_mrg_to_branch1 entire_repository
cvs update -d -P -j branch1 -j branch2_mrg_to_branch1
( make branch1 equal to branch2 )
cvs commit
[smc] [...snip...]
> > So again, my questions to you are:
> > 1. What operations on branches do people really want/need/use?
>
> To be truthfull, I very rarely use branches. They are rather painfull to
> work
> with. (The one admission I'll make...) But when they are necessary, then
> no
> other method really works...
[smc] Hmm. Why do you say that? Maybe it's just a matter of
practice.
We use branches exclusively... (we never commit to the trunk, except
when creating a new branch.)
There is some tagging maintenance you have to do with branches,
and the pitfalls could probably be better documented.:
Two of the pitfalls can be avoided this way:
1) Always, always always create a regular tag marking the origin of
the
branch before creating the branch, otherwise you will have no way to
refer to this point later, in case you need to.
e.g. don't do
cvs tag -b my_branch
Instead do:
cvs tag my_branch_origin
cvs rtag -r my_branch_origin my_branch
2) When doing merging, always use a tag to mark what has been merged
so subsequent merges are possible without remerging what has already
been merged. Establish a naming convention for
these tags so it is easy to remember what they mean. (or keep
careful
notes. Many people suggest CVS should automate much of this
tagging,
but, merging is so flexible...you don't have to merge the enitre
repostiroy,
you can merge backwards as well as forwards, etc. The solutions
I've seen
proposed seem to fit one model, but not be very general purpose...)
[smc] [..snip..]
-- steve
>
