Eugene Kuleshov <eu@md.pp.ru> wrote on 03/15/2006 03:21:09 PM:
> > 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 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.
> > 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.
> 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.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
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:33:03 2006