Re: [Subclipse-users] What is Tags column on Resource History used for?
From: Eugene Kuleshov <eu_at_md.pp.ru>
Date: 2006-03-15 20:46:24 CET
Does that described in documentation? I don't think there are many Subclipse users yet that can read your mind. :-)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.
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?
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?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.
What constraints you are talking about? How hard it to write few lines of code like: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.
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.
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.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.
--------------------------------------------------------------------- To unsubscribe, e-mail: firstname.lastname@example.org For additional commands, e-mail: email@example.com Received on Wed Mar 15 20:46:57 2006
This is an archived mail posted to the Subclipse Users mailing list.