On 7/6/05, Simon Large <firstname.lastname@example.org> wrote:
> Daniel Atallah wrote:
> > I do understand the logic of displaying the history in the From URL,
> > but for our usage (which I'm guessing is pretty common), the current
> > functionality is somewhat non intuitive.
> Seems we are missing a common use case then.
> > Like many projects that are in a production environment, for our
> > current release, we have a "stable" branch and a "testing" branch.
> > Bugfixes and enhancements and developed against the testing branch.
> > What happens when a change is ready to be deployed to our production
> > servers, is that we merge the specific changes from the testing branch
> > to the stable branch. These changes are usually several revisions,
> > but are not necessarily sequential. Because we are working with a
> > codebase that is quite large, and these changes are often isolated to
> > a small sub section of the project, the merge is often done on
> > specific sub directories, or even files. The fact that we're
> > frequently merging at many different levels makes the history listing
> > in the merge dialog less useful for us because the default URL is
> > almost always "wrong" and requires two changes - (it needs to be
> > updated to point at the current working copy and then the branch name
> > changed).
> I don't really understand why your 'From:' URL wants to be the same as
> the WC URL. Maybe I've got that bit wrong, but if you could provide a
> worked example then we might understand your use case better. If you can
> give us some real paths and revision numbers it would help. Maybe your
> repository structure is different from what I have assumed.
A example is an excellent idea, perhaps it will help to illustrate the problem.
Our source tree is structured in a single repository, there are
several core modules, and each of those has several "sub modules".
I've changed some of the names in the paths to protect the innocent.
Lets say that yesterday I merged changes to some customer-specific
integration code from the "testing" branch to the "stable" branch, the
merge was done on the below path:
I right-clicked on the "inbound" sub directory in my working copy and
chose "Merge" to do this.
Now, that all worked magically wonderfully - lets not worry about how
the From URL got populated in this case.
(Assume that my local working copy has been checked out at the "MainApp" level.)
So, today, I realize that another set of changes in a different part
of the application are ready to be merged, so I go to the directory
where I want to do the merge:
This corresponds to:
on the server.
I right-click on the "coredit" directory and choose "Merge". Now, in
the "From" URL, instead of seeing
it says "http://svn/branches/RLS_6-5-5_test/Lampert/MainApp/Integration/src/com/somecompany/intg/customer/customername/inbound"
(the last place that was merged from).
So, what needs to be done, is to replace the URL with the current WC
URL and then replace the branch name ("RLS_6-5-5") with the testing
branch name ("RLS_6-5-5_test") before I can enter the revisions
(25319:25325) and do the merge.
Hopefully this outlines why I think that it would be useful to have
the current WC URL as the default "From" URL.
One thing that makes our situation even more prone to failure is that
often the revision numbers that are used for the merge are often not
obtained from the "Show Log" look up, but rather copied from the
change documentation which was created by the developer who did the
commit. I will encourage people to use the "Show Log" to verify their
revision numbers (this also should help make sure that they have the
The argument can be made that the only reason the problem occurs is
that people are being "sloppy", and that is true, however, I still
think it makes sense to display the current WC URL by default and to
allow the user to make changes because (at least in our case) the real
URL will be almost identical to the WC URL, with only the branch name
I hope this isn't too convoluted.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Jul 6 18:35:05 2005