Re: [Springframework-developer] @since and @version tags

[Colin S. <col...@ex...>]

I do like $Id tags to be able to look at files and see who to blame for 
the last changes :-), but I would rather be able to branch/merge 
comfortably in the future. With Tortoise and Eclipse, I can see the 
revision history _very_ easily anyways, wherever I am.

So -1 for using them from now on (i.e let's get rid of them)...


Dmitriy Kopylenko wrote:

> Well, let's take a vote. I'm for $Id tags (+1)
>
> Regards,
> Dmitriy.
>
>
> jürgen höller [werk3AT] wrote:
>
>> I'd actually prefer if we drop $Id tags from all files. I personally 
>> don't think that they add much value. Of course, if a democratic 
>> decision goes in favor of those tags, well, I'll concede ;-)
>>
>> Regarding @since tags, we're currently using them with the creation 
>> date. That has been quite nice during our agile way towards 1.0. We 
>> could indeed reconsider to use version numbers there now.
>>
>> Any suggestions on how to apply a consistent style for all source 
>> files in a batch, without messing them up? $Id is probably easy, 
>> @since nearly impossible, parameter alignment easy again.
>>
>> Juergen
>>
>>
>> ________________________________
>>
>> Von: spr...@li... im Auftrag 
>> von Colin Sampaleanu
>> Gesendet: Mi 28.07.2004 20:38
>> An: spr...@li...
>> Betreff: Re: [Springframework-developer] @since and @version tags
>>
>>
>>
>> Dmitriy Kopylenko wrote:
>>
>>  
>>
>>>> I like id keywords...they're mainly in the code through my classes or
>>>> classes I've edited... (Damn, if it's standardized, I won't know if 
>>>> I've
>>>> worked on a particular file any more :-)
>>>>
>>>>
>>>>     
>>>
>>> I also insert $Id:$ when I work on existing classes or create new ones
>>> ;-)
>>>
>>> Dmitriy.
>>>   
>>
>>
>> I personally like $Id tags. But they do suck big time when trying to
>> merge files back in after a branch, causing a conflict/change to exist
>> when there shouldn't be any... There seems to be a trend to going away
>> from using them in files, by some people, for this reason.
>>
>> Colin
>