[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 21:54:15 CET

Mark Phippard wrote:

>>>> BTW, you didn't respond to my question why revision is needed in
>>>> tag property and it does not described in the documentation.
>>> The revision is the main thing we need. It is used in the history
>>> view to know which revisions to decorate with which tags. It would be
>>> impossible to discover that information dynamically.
>> I wouldn't say it is impossible.
>> Since that property is on the project level you can scan trough all
>> tags/branches it is describing once and save discovered revisions
>> locally.
> I thought the point of this part of your argument was about not having the
> property at all. What would be the benefit of adding all of this extra
> checking? What is wrong with storing the revision?

   I was suggesting to remove revision from the property, but not
property itself.
   The reason to eliminate revision is that you can commit tag property
before creating branch when revision is not known.

>>>> 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.
>>> I don't think I agree, but I am not sure I understand either. I think
>>> the feature is working correctly if you trace it out.

>> Let's start over. I could be wrong, but here is what I saw:
>> 1) head version
>> 2) create tag1 from head
>> 3) history for head shows tag1
>> 4) history for tag1 shows no tag1
>> 5) create tag2 from head
>> 6) history for tag2 shows tag1 but not tag2
>> 7) create branch1 from tag1, history for branch1 shows no tag1.
>> I think 7) is a big problem. 6) and 4) also problems but probably
>> smaller ones.
> OK, I at least see what you are saying now. I see 7 as a relatively minor
> problem since the property can be edited in the branch and since it could
> be worked around by making the branch from source of the tag instead of
> the tag. I do not see 4 and 6 as problems at all, although I will concede
> that 7 would not be an issue were it not for 4 and 6.

   Well, I'd say that users would like it better if tag info (property)
gets propagated without additional editing. In case of tags it is even
bad idea to edit that info.

   I think that 4) and 6) are problems because user can't compare
current code with initial tag revision. Well, this is actually more
applicable to branches.


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:56:11 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.