Mark Phippard wrote:
>>> Let me rephrase this to see if I understand:
>>>
>>> 1) Select more than one project in say the Navigator view or Package
>>> Explorer --- Eclipse view. I think we can do this conditioning right
>>> in the option contribution to the menu.
>>>
>>> 2) Find common parent URL of selections. If none exists probably
>>> issue an error message.
>> I don't think you need parent here. Copy is created for selected
>> projects and not for their parents.
>
> That means you have to do a mkdir and then N copies, resulting in N + 1
> commits. You really think that is what people would want?
I think it wouldn't matter in most of the cases and it will be
definitely faster then doing that manually from the UI for each project
individually. Besides tag/copy is fast operation in svn, isn't it?
From other hand I don't mind if you want to optimize it to the parent
folder, but not sure how would you make sure that parent folder don't
have any other projects that hasn't been selected for given tagging.
>>> I am going to change your script at this point to reflect what I would
>>> actually consider doing.
>>>
>>> 3) Bring up Create tag dialog based on this common parent URL.
>> However here we are choosing parent target folder where all copies
>> will be created.
>
> Right, they all go to the same target such as url://repos/tags/version1
>
>>> 4) If tag is created, for each of the selected projects update the
>>> subclipse:tags property if it is present.
>>>
>>> I will not even consider doing any "commits" as part of this process,
>>> so I left that out. User would have to commit any subclipse:tags property
>>> changes after the tag is created.
>> And why exactly you won't even consider that? If tag property won't
>> have revision information it would be quite reasonable to commit it
>> before hand if user choose to tag with head revision.
>
> There is no way I am going to initiate a commit in the middle of this
> process. That would mean having to collect a commit message and also the
> commit will only succeed if the folder with the property is at the HEAD
> revision.
I am not suggesting to initiate commit in a middle. Once user specify
all required info (which is basically a target folder to copy) Subclipse
would sequentially run all required svn commands and required commit
message can be filled in automatically (e.g. "updated tag information
for XXX tag/branch).
>>> Setting aside the parts we disagree on, would you say that this is
>>> what you are suggesting? Essentially creating a tag based on the common
>>> parent of the selections?
>> Not really. I wasn't suggesting parent, especially because such
>> parent may have more stuff then user actually want to tag. Unless I am
>> missing something.
>
> In some cases it certainly would. I guess what I was hearing, was that
> you would essentially be doing the same create tag that you would have
> done from the repositories view, except with this technique the property
> could also be maintained and in many cases it would be more obvious to the
> user.
Simplicity is important. Also it would save a lot of time when
tagging multiple projects and want to maintain property with tag info.
>> I also think it is important that one way or the other tag property
>> will go into the copy. Because the only way to make it go to the target
>> copy is to actually commit it, it need to be committed automatically.
>
> And I don't see why it would ever be needed or wanted, let alone important
> or necessary. I am not trying to be insulting, but I still do not think
> you understand the feature as well as you say you do.
I am not even pretending to understand it. :-)
See my other email that is describing scenario I am concerned about.
regards,
Eugene
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Wed Mar 15 21:46:13 2006