Menu
▾
▴
springframework-developer
|
From: Dmitriy K. <dko...@ru...> - 2004-07-27 18:20:07
|
I think it was discussed before, but I just wanted to re-iterate. I just want to be consistent with our javadoc style. I noticed there are some @since tags with the date. Personally I would prefer the release version as it's easier to see since what version the file (class) was introduced, i.e @since 1.0.2. Also not all the files have @version tag with CVS $Id$ keyword substitution. So I would propose the standard javadoc template for every class, something like this: /** * <Insert type description> * * @author <Developer Name> * @since <Release version> * @version $Id:$ */ ...plus any optional tags such as @see What does everyone think? Regards, Dmitriy. |
|
From: Rod J. <rod...@in...> - 2004-07-27 19:34:21
|
> I think it was discussed before, but I just wanted to re-iterate. I just > want to be consistent with our javadoc style. I noticed there are some > @since tags with the date. Personally I would prefer the release version > as it's easier to see since what version the file (class) was > introduced, i.e @since 1.0.2. Good point. Maybe keep @since a date for things that predated 1.0? > > Also not all the files have @version tag with CVS $Id$ keyword > substitution. So I would propose the standard javadoc template for every > class, something like this: > > /** > * <Insert type description> > * > * @author <Developer Name> > * @since <Release version> > * @version $Id:$ > */ > > ...plus any optional tags such as @see +1. That looks like my code template (except I don't have @since). 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 :-) Rgds Rod |
|
From: Dmitriy K. <dko...@ru...> - 2004-07-28 17:39:19
|
>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. |
|
From: Colin S. <col...@ex...> - 2004-07-28 18:39:32
|
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 |
|
From: <jer...@xt...> - 2004-07-28 20:48:32
|
Colin Sampaleanu wrote: > 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. Simply use the "-kk" option. Have a look at: http://www.loria.fr/~molli/cvs/doc/cvs_toc.html#TOC96 Keywords are not an issue at all for branches & merges. Jérôme. |
|
From: Colin S. <col...@ex...> - 2004-07-28 21:36:22
|
Jérôme BERNARD wrote: > Colin Sampaleanu wrote: > >> 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. > > > Simply use the "-kk" option. > Have a look at: http://www.loria.fr/~molli/cvs/doc/cvs_toc.html#TOC96 > Keywords are not an issue at all for branches & merges. > I think I'm missing something. If you just use -kk, then you don't get any actual values substituted, only the keyword itself gets left in there. Are you suggesting that for doing the merge, you check out both branches with -kk, and then merge using those copies? Sort of a pain, although it would work. Colin |
|
From: <jer...@xt...> - 2004-07-29 07:31:16
|
Colin Sampaleanu wrote: > Jérôme BERNARD wrote: > >> Colin Sampaleanu wrote: >> >>> 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. >> >> >> >> Simply use the "-kk" option. >> Have a look at: http://www.loria.fr/~molli/cvs/doc/cvs_toc.html#TOC96 >> Keywords are not an issue at all for branches & merges. >> > I think I'm missing something. If you just use -kk, then you don't get > any actual values substituted, only the keyword itself gets left in > there. Are you suggesting that for doing the merge, you check out both > branches with -kk, and then merge using those copies? Sort of a pain, > although it would work. > > Colin I should have sent this link instead http://www.rons.net.cn/htp/cvs/cvs_5.html#SEC64 :-) Basically, with the "-kk" option, it simply ignores the "expanded values". No need to checkout with "-kk". Jérôme. |
|
From: Colin S. <col...@ex...> - 2004-07-29 12:10:09
|
Jérôme BERNARD wrote: > Colin Sampaleanu wrote: > >> Jérôme BERNARD wrote: >> >>> Colin Sampaleanu wrote: >>> >>>> 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. >>> >>> >>> >>> >>> Simply use the "-kk" option. >>> Have a look at: http://www.loria.fr/~molli/cvs/doc/cvs_toc.html#TOC96 >>> Keywords are not an issue at all for branches & merges. >>> >> I think I'm missing something. If you just use -kk, then you don't >> get any actual values substituted, only the keyword itself gets left >> in there. Are you suggesting that for doing the merge, you check out >> both branches with -kk, and then merge using those copies? Sort of a >> pain, although it would work. >> >> Colin > > > I should have sent this link instead > http://www.rons.net.cn/htp/cvs/cvs_5.html#SEC64 :-) > Basically, with the "-kk" option, it simply ignores the "expanded > values". No need to checkout with "-kk". Ok, I see what you are getting at. The issue is that this overrides the binary mode on files that are binary. Not very realistic in a large codebase. Colin |
|
From: jbetancourt <jbe...@co...> - 2004-07-27 23:44:10
|
BTW, CVS keyword expansions can make some things like branching and merging very difficult. For example, the $Id$ always show as conflicts and some command line options to get around them play havoc with binary files. Disregard if branching is not applicable in this project, or if I'm incorrect regarding CVS branching difficulty. -- J. Betancourt ----- Original Message ----- From: "Dmitriy Kopylenko" <dko...@ru...> To: <spr...@li...> Sent: Tuesday, July 27, 2004 2:20 PM Subject: [Springframework-developer] @since and @version tags > I think it was discussed before, but I just wanted to re-iterate. I just > want to be consistent with our javadoc style. I noticed there are some > @since tags with the date. Personally I would prefer the release version > as it's easier to see since what version the file (class) was > introduced, i.e @since 1.0.2. > > Also not all the files have @version tag with CVS $Id$ keyword > substitution. So I would propose the standard javadoc template for every > class, something like this: > > /** > * <Insert type description> > * > * @author <Developer Name> > * @since <Release version> > * @version $Id:$ > */ > > ...plus any optional tags such as @see > > What does everyone think? > > Regards, > Dmitriy. > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Dmitriy K. <dko...@ru...> - 2004-07-28 00:00:48
|
I don't think we should be concerned about branching, unless we are planing to do a branch any time soon. Are we? Dmitriy. jbetancourt wrote: >BTW, CVS keyword expansions can make some things like branching and merging >very difficult. For example, the $Id$ always show as conflicts and some >command line options to get around them play havoc with binary files. >Disregard if branching is not applicable in this project, or if I'm >incorrect regarding CVS branching difficulty. > >-- J. Betancourt > > > >----- Original Message ----- >From: "Dmitriy Kopylenko" <dko...@ru...> >To: <spr...@li...> >Sent: Tuesday, July 27, 2004 2:20 PM >Subject: [Springframework-developer] @since and @version tags > > > > >>I think it was discussed before, but I just wanted to re-iterate. I just >>want to be consistent with our javadoc style. I noticed there are some >>@since tags with the date. Personally I would prefer the release version >>as it's easier to see since what version the file (class) was >>introduced, i.e @since 1.0.2. >> >>Also not all the files have @version tag with CVS $Id$ keyword >>substitution. So I would propose the standard javadoc template for every >>class, something like this: >> >>/** >> * <Insert type description> >> * >> * @author <Developer Name> >> * @since <Release version> >> * @version $Id:$ >>*/ >> >>...plus any optional tags such as @see >> >>What does everyone think? >> >>Regards, >>Dmitriy. >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by BEA Weblogic Workshop >>FREE Java Enterprise J2EE developer tools! >>Get your free copy of BEA WebLogic Workshop 8.1 today. >>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click >>_______________________________________________ >>Springframework-developer mailing list >>Spr...@li... >>https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> > > > > >------------------------------------------------------- >This SF.Net email is sponsored by BEA Weblogic Workshop >FREE Java Enterprise J2EE developer tools! >Get your free copy of BEA WebLogic Workshop 8.1 today. >http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Dmitriy K. <dko...@ru...> - 2004-07-28 19:01:45
|
So, what is the consensus here? Are we planing to do any branches? Colin Sampaleanu wrote: > 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 > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
