Mark Phippard wrote:
I see. So, now I can choose to make a copy from trunk in tag/branch
dialog and according to you this dialog will update tag property prior
copying to target folder? I can understand what is happening there, but
it is not quite transparent. Please correct me if my guesses are wrong:
No, you are already wrong. If you are working locally, and the item you
selected contains this property, then AFTER the branch/tag is made, the
local property is updated. It would then still need to be committed.
Does that described in documentation? I don't think there are many
Subclipse users yet that can read your mind. :-)
I probably understand why you have to do it AFTER branching. But what
I don't understand or already forgot is why do you need revision for
every tag in that property? Can't it be queried (and cached locally if
necessary) when doing comparison against tag?
1) If I choose "HEAD revision in repository" in tag/branch dialog, then
tag property will not go into target cop, unless I manually create it
before calling tag/branch dialog
2) If I choose "Working copy" in tag/branch dialog, then property will
be created locally, but not committed and will also go into target copy.
This is what I'd like to see documented. More over I'd prefer that
property would be committed to head for me before doing copy in case 1)
The property would never go into the target of the copy. Or rather, what
properties do go into the target are just based on the rules of a
Subversion copy. This process does nothing that would alter this. The
property management it does do, happens after the copy.
The thing is that this property would go into the next tag "based on
the rules of a Subvesion copy", but not into the tag it is describing.
Don't you find that confusing?
Also it does not work when you need to tag multiple projects. Look at Subversion's own project structure as an example. It is not that uncommon when you have to tag 3 to 10 projects when releasing new version of Eclipse plugin. How Subclipse is helping with that?
It doesn't and can't. So what?
That is where we disagree. It could, but you didn't want it.
You got me. I wanted to make sure this feature was difficult. It had
nothing to do with the constraints that exist. I spent weeks adding the
feature and documenting it just for the hell of it.
What constraints you are talking about? How hard it to write few
lines of code like:
1) check that all selected elements are projects (done in plugin.xml)
2) select same target folder for all of them
3) for each selected project:
-- update tag property file for each of them (considering above
comment about revisions)
-- commit tag property
-- create copy of project in selected target folder
It is an IDE and the main purpose of IDE is to make common operations
simple. Otherwise I can go to command line and run script that will do
all of that.
Should we have not added the feature? Is
it that hard to manually manage the property?
It is easy for single project, but annoying and time consuming and
error prone when you have to do it for 10 projects. Besides, it is easy
to forget to do so. This is not really IDE-friendly behavior.
We knew before the feature was implemented that it had to be a hack.
Everyone insisted that it was worth it for the benefits it would provide.
I must confess that I really like the feature now that it exists. Make a
suggestion that shows you spent even two minutes trying to understand the
feature and what the Subversion API's and constraints are and I will
listen.
I do think that it is very reasonable workaround and I was one who
actually commented to initial proposal. However there are some
shortages that still have to be worked out.
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 20:46:57 2006