Mark Phippard wrote:
> I think it is. This is what the docs say:
>
> Updating the Property
>
> In addition to the Configures Branches and Tags option that was discussed
> earlier, there is also support for automatically updating the
> subclipse:tags property when you create a Branch/Tag using Subclipse. When
> you take this option, if we detect the subclipse:tags property on the item
> you selected, then we pop-up a dialog that lets you confirm that you want
> to add this new information to the subclipse:tags property. You then just
> have to commit that property change after creating the Branch/Tag. This
> feature does not exist when creating the Branch/Tag from the repository
> browser as it is only possible to modify a property value in a working
> copy.
Found it now. Thanks.
It think it is more important then description of obvious actions
like how to compare with tags. So, perhaps you can put this section
right after description of property management dialog? Also add an
context index at the top of the page that would have links to sections
within this page.
BTW, you didn't respond to my question why revision is needed in tag
property and it does not described in the documentation.
>> 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?
> Honestly, I don't. This feature exists for one main reason, so that when
> browsing the history for an item we can decorate it with tags. Why would
> the tag itself need informatiom about itself? That would already show in
> the history of the tag. However, when creating a branch having this old
> information flow into the branch is very handy. When browsing the history
> of a branch as it traces back into its source you can still see the
> decorations.
Right, but creating a tag from branch copy won't show you the initial
tag information because it was left behind in a head. That is what I am
trying to say.
>> What constraints you are talking about? How hard it to write few
>> lines of code like:
> Constraints such as that Subversion does not allow you to set a property
> directly in the repository. It has to be set on a working copy and then
> committed. Constraints such as that Subversion does not let you perform
> "atomic" operations on "disjointed" working copies. In the typical
> Eclipse workspace, each checked out project is its own working copy
> island. You cannot create one tag from all of these islands.
I am well aware of that, but I believe it is acceptable to execute
several subversion operations within single Eclipse action. You can
provide preference for paranoid users who don't want to use that and
want to disable such operations.
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:13:05 2006