SteveKing wrote:
> Mark Phippard wrote:
>> 1) Running multiple merges could become very tricky and introduce a
> So my reaction to this would be: we don't allow it.
Agreed. It was a great idea, but we'll need to hire tech support staff
to handle the mailing list.
>> 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
One improvement here might be to add a 'show log' button for the WC, not
for selecting revisions but for looking for those magic commit messages
which tell you the last revision you merged.
> So let's discuss on how to improve the merging as it is right now,
> with the features that exist.
Agreed. Merge tracking is the holy grail, but it has to be done in SVN.
> 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).
See comments in an earlier response about the dangers of using HEAD.
>> 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.
> 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.
Of course. There's no point in starting if we just end up with a
different set of confused users.
One idea that occurred to me was to keep the dialog basically as we have
it now, with the subtract 1 feature, essentially following the CLI, but
add another helper dialog which fills in the fields for you using some
of the methods we have discussed. I will need to think it through a bit
further before I am convinced it is a good idea.
Simon
--
___
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 19:16:58 2005