Mark Phippard wrote:
> My initial reaction is that I do not like it, but I think that might
> partially be because I do not understand some of the ideas you have for
> using the log dialog. I am certainly not against giving your proposal a
> shot. All that being said, here are just some thoughts I have, some are
> in response to subsequent comments you have made.
>
> 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.
> 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.
> 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.
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).
> 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).
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 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).
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Jan 24 18:33:41 2005