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

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
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 
  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.


--------------------------------------------------------------------- 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

This is an archived mail posted to the Subclipse Users mailing list.

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