On Thursday, Nov 6, 2003, at 12:51 US/Pacific, John Peacock wrote:
> If the tags only exist in the local repository then two people working
> on the same branch would not have the same mergepoint information. > ...
> [example snipped]
> If the mergepoint info is in the local sandbox, then User B will not
> be able to perform a merge from trunk at this point without checking
> exactly where each file was merged with trunk (using 'svn log' for
> example). User A can just repeat the same merge command and get only
> the trunk changes after the last merge.
Let me see if I understand this example correctly: when user A (call
him Al) wants to work on something, Al creates a local branch of the
public trunk. The tag is actually created at the base of that local
branch (not at the base of the trunk, as I had assumed). As time goes
by and Al merges in updates from the public trunk, the tag of the local
copy is updated. When Al pushes a changeset, it shows up as a branch
in the public repository with the tag at the base of the branch. User
B (call her Barb) can then check out the branch and the knowledge of
the mergepoint is attached.
Have I got it? If so, then this seems perfectly reasonable. There are
indeed some interesting problems to be solved if Al and Barb make
independent merges thereafter, but I suppose that's not a problem that
needs to be cured immediately. And now admin C (call him Chuck) can
easily merge the changeset into the trunk and only apply the changes
actually made in the branch, yes?
Correct me if I'm wrong, but isn't tracking mergepoints like this
intended to be part of the basic SVN processing? If not now, then
someday? And if that's the case, shouldn't there be some concern about
how this will impact that functionality?
And then there's the scenario where the user doesn't create a branch,
but applies his changes directly to the (local) trunk, merging from
time to time from the public repository. What happens when he pushes
that changeset? (This is how I was thinking it would be done; work on
changes locally, commit them locally as needed to keep track of what
you're doing, then ship the finished modifications as a single
Just color me confused,
-- Greg Noel, retired UNIX guru
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Nov 7 13:16:42 2003