[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Re: Suggestion: Branch/tag-dialog change

From: Hans-Emil Skogh <Hans-Emil.Skogh_at_tritech.se>
Date: 2006-06-22 09:02:53 CEST

>> I would like to suggest a modification to the "Copy (Branch / Tag)"-dialog.
>> In my opinion we should change the order (and default selection) of the
>> radio button choices.
> I don't like the idea of moving controls around. We had *exhausting*
> discussions about the branch/tag and merge dialog already on how to do
> it best. And I really don't want to get there again...
I wasn't aware of that... Then I simply trust in your good judgement in this case.

>> The reason I'm suggesting this is because it's an unsafe working
>> practice to make a tag from repository-HEAD since there's no way to know
>> what you are tagging.
> While I agree with you that in general, creating a branch/tag directly
> from HEAD is bad (someone else could commit while you don't expect it),
> I'm not sure if we should fill in the revision of the working copy. As
> you might know, there just is no single working copy revision. We'd have
> to do the same as SubWCRev does now (find the highest 'last committed'
> revision), which takes a while to compute.
> Thoughts?
Wouldn't it be possible to get the revision in the same way as it is done on the TSVN-tab on the explorer properties page?
You are right-clicking something when selecting "Branch/Tag" and I would imagine that it would suffice of getting the revision of that object, or maybe that's already done in the SubWCRev-fashion?

>> I would also suggest changing some texts to clarify:
> Again (see above) I don't want to change any text or controls in that
> dialog unless there's a *very, very good reason* for it.
Ok. For me they seemed a bit (slight understatement) unclear, but I can definitely live with them if they make sense to everyone else.
Received on Thu Jun 22 09:02:46 2006

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.