SteveKing <steveking@gmx.ch> wrote on 01/24/2005 12:33:01 PM:
> Mark Phippard wrote:
> >
> > 1) Running multiple merges could become very tricky and introduce a
lot
> > of side effects you were not expecting. I do not know what those all
are,
> > but it just seems logical to me that if a file was changed multiple
times
> > within the range, or other things like that, then you could run into
> > problems.
>
> It would cause problems _only_ if a file that has been changed in more
> than on revision range _and_ if one of those cause a conflict in that
> file. Then subsequent merges will completely fail. And I guess then the
> user would have to find out which merges worked ok and which failed.
> So my reaction to this would be: we don't allow it.
What if the same revision range was changed multiple times across
revisions? If a single merge was done, Subversion would just figure this
all out based on the final version, but if multiple merges were done, on
the surface it would seem that it could increase the amount of conflicts,
and in the case the conflicts are sort of artificial in that they are just
a by-product of the way the merge was performed.
> > 2) I most often use the "long-lived" branch approach, where I am
keeping
> > a branch up to date with trunk. When I work on a branch, the way I do
a
> > merge is to Show Log on my WC so that I can find the last revision I
> > merged. I then take the merge option, find the URL in the drop-down,
type
> > the revision I previously looked up, and then usually click HEAD for
the
> > To revision. What would help this process the most is to have the
merge
> > dialog intelligently remember what I did the last time, and pre-fill
with
> > that information. Ideally, it would take the To revision of my last
merge
> > and make it the From revision. If nothing else, just having the URL
>
> What you want here is a completely new feature! This feature called
> "merge tracking" is on the Subversions todo list:
> http://subversion.tigris.org/roadmap.html
> A file describing how it might get implemented is here:
> http://svn.collab.net/repos/svn/trunk/notes/merge-tracking.txt
>
> This is a really difficult issue. If we just implement it 'the fast way'
> then we will get all kinds of problems. And it would be even worse if we
> start implementing something, users get used to it and then as soon as
> Subversion supports that in the library we have to change it to match
> their implementation - then users have to get used to something which
> might only be slightly different --> many, many problems, "bug" reports,
...
>
> So let's discuss on how to improve the merging as it is right now, with
> the features that exist.
I prefer to think of this as a "poor-man's merge tracking". Basically, it
is just making the default UI more intelligent. I think that the
Subversion merge tracking is about more than the UI, but also in the merge
process itself. Currently, the default UI is not terribly useful since it
just loads the URL of the WC. That URL would rarely be used in a merge. I
think the only scenario would be to "undo" a commit. I think that
remembering previous values and using those as the default the next time
would just be a nice usability improvement. I think you are exaggerating
a tad when you say this would lead to many problems and bug reports.
> > 3) I personally like the way you input revisions in the current
dialog
> > better than typing in a URL. I can probably get over it. Would I
enter a
> > range like this?
> >
> > url://host/project/trunk_at_123:456
>
> No. If you merge revisions from _one_ other URL, you open the log dialog
> and select the revisions you want to merge from there.
So in my scenario, the only way to specify my revision range is to use the
Show Log dialog and select them? If so, please shoot me right now.
> If you want to merge two URL's, then you have to specify the revisions
> with the URL (however, that approach almost always will have the HEAD
> revision given, so it will default to HEAD and so users won't even
> bother entering a revision number there anyway).
Agreed.
> > 4) I am torn about figuring out the right range for the user (in
other
> > words subtracting one automatically). I think that could ultimately
add
> > to the confusion. At a minimum, I would at least recommend that the
> > revisions you show in the dialog, are the ones you are going to pass
to
> > the command. So if I select revisions 100-200 in the Show Log dialog,
you
> > should show 99-200 when I come back.
>
> That depends. I would say I just show the selected revisions, but with a
> label telling "Revisions to merge" and not "Merging from XXXX to YYYY".
>
> > Personally, I would rather see you move in the direction of Simon's
last
> > design for the UI and then try to incorporate some of your ideas into
> > that. In other words, let's try to improve the terminology but also
lay
> > out the dialog so that the WC is the last item shown. I think that
> > emphasizes the From -> To -> Into relationships. I think you could
take
> > his basic design and still add your ideas for how to use the Show Log
> > option. This would make the dialog still easy to use for people like
me
> > that know what we are doing, but also provide some ease of use for a
> > novice.
>
> So now I don't know what to do anymore. If we do what you're suggesting,
> the user would still have to enter the revision numbers with 1
> subtracted from the revision to merge. And that's exactly the problem
> this discussion was all about (that and of course the "from"/"to"
problem).
Personally, I think the from/to problem has always been the main problem.
As for the other problem, what I was saying is that you could make
selecting the revision from Show Log subtract 1 before showing the value
in the dialog. Personally, I do not think the rev number minus 1 issue is
a big problem. Is it initially confusing? Sure. But it is not that hard
to learn. Merge is not a trivial operation, eventually the person doing
it needs to understand what they are doing.
> We can't do both (entering the revisions to merge or entering the
> revision the same way as the CL client with one subtracted). We have to
> come to an agreement here - otherwise I won't change the merge dialog
> since it would only start a weekly change in the dialog until no one
> knows anymore how it works.
I am not convinced that this idea of letting the user "cherry-pick"
revisions to merge is a great idea anyway because it means you have to
execute multiple merge commands which could have bad side effects. You
would effectively be pushing the problems out of Subversion and into
TortoiseSVN by taking on that role. I will admit that for someone that
had the need to do that kind of merge, your idea is wonderful. I just do
not agree that the UI should assume that is the primary type of merge that
is done and optimize the UI in favor of that scenario.
Please do not get discouraged by my comments. I think you have some good
ideas, and truth be told, if the nightly build just suddenly had this new
dialog, it all just might work out OK. A lot of these objections are
theoretical at the moment, and it is possible that if we started with a
new dialog, we could all provide some feedback for tweaking it this way
and that.
My personal preference would be to go back to some of the original
discussion to see if simply changing the terminology and layout of the
existing dialog could make this a little more intuitive. I think it is
possible.
> > I also think you would get a big usability win if you either
remembered
> > the last URL used for a merge in that WC, and/or in the remembered URL
> > list for this dialog, saved the list by WC. We do the latter in
Subclipse
> > and it really helps the UI. In my case, there is always just one
> > remembered URL for each project and this makes it much easier to use.
>
> That's already done. The URL history is now kept by WC (not for the
> checkout dialog of course).
Any reason why I do not see this? I have a few WC's directly off my C:\
drive. C:\Proj1 C:\Proj2 etc... When I do merges for these WC's, I seem
to see just about every URL that has ever been typed. Anything I can look
at in the registry? My commit messages seem to be properly remembered by
project, but the URL's.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Jan 24 19:26:24 2005