Menu
▾
▴
fofredux-devel
|
From: Andrew T. (nilspace) <nil...@us...> - 2005-11-23 04:04:17
|
Hi all, I've added Carlos & Kevin to the FoFRedux developers. You will be able to check in and out now. I've also assigned your respective tasks. Carlos, can you apply the timestamp patch of yours? Also, Kevin, I think you mentioned you could add tags? Andy -- Andrew Turner ajt...@hi... 42.4266N x 83.4931W http://highearthorbit.com Northville, Michigan, USA idealistic technocrat Photos - http://flickr.com/photos/ajturner Travel - http://highearthorbit.com/projects/location/ |
|
From: Benjamin S. <bs...@cr...> - 2005-11-23 04:48:13
|
Do we have plans for code reviewing going forward? Like, here's my diff, here are comments from someone else, dev responds to comments, changes made, and done? =20 Here's what I've found works really well when working with branches in cvs: 1. once you're ready to submit, make a LIST of your files. 2. add a tag PRE_CHECKINLABEL to ONLY those files (using your list) 3. check in=20 4. add a tag PRE_CR_CHECKINLABEL (Code Review) to ONLY those files 5. make changes as appropriate for the CR and check in again and get CR approval 6. add a tag POST_CHECKINLABEL to ONLY those files This way, you can double -j when merging those changes around based on the tags, and you're not relying on cvs's insane file versions, and the pre cr tag allows you to back a change out a lot easier. And I *think* the reason to only tag your specific files is because it makes it easier to figure out what files are changed by any given change, though I'm not sure that's it -- whatever it was, we had a really good reaosn for that policy (and I don't think it was just that some of my fellow engineers were idiots and I didn't trust them not to check in all of their global changes if they weren't using file lists). That said, I highly advocate you ONLY use cvs with a file list if you're doing operations that add/delete/commit/tag/otherwise write data to the repository. It's not worth the mistake of accidentally checking in something you didn't mean to check in -- everyone's done it. My plan is to spend a little bit of time over thanksgiving merging my keyboard shortcuts onto what Andy did, and hopefully have a checkin on a branch by Monday or Tuesday of next week. =20 In general, though, what I've done will be pretty easy to redo with whatever changes other people make, so it's not a big deal if that gets delayed a touch. For an initial release, I think having *any* keyboard shortcuts without ajax features is fine; We can add ajax features later, and I think the ability to fly through posts is a bigger deal. -Benjy On Tue, Nov 22, 2005 at 11:04:13PM -0500, Andrew Turner (nilspace) wrote: > Hi all, > I've added Carlos & Kevin to the FoFRedux developers. You will be able > to check in and out now. >=20 > I've also assigned your respective tasks. Carlos, can you apply the > timestamp patch of yours? Also, Kevin, I think you mentioned you could > add tags? >=20 > Andy >=20 > -- > Andrew Turner > ajt...@hi... 42.4266N x 83.4931W > http://highearthorbit.com Northville, Michigan, USA > idealistic technocrat >=20 > Photos - http://flickr.com/photos/ajturner > Travel - http://highearthorbit.com/projects/location/ >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_idv28&alloc_id=16845&op=3Dclick > _______________________________________________ > Fofredux-devel mailing list > Fof...@li... > https://lists.sourceforge.net/lists/listinfo/fofredux-devel |
|
From: Kevin <ke...@dr...> - 2005-11-27 15:23:35
|
Benjamin Stewart wrote:
>Do we have plans for code reviewing going forward? Like, here's my
>diff, here are comments from someone else, dev responds to comments,
>changes made, and done?
>
>Here's what I've found works really well when working with branches in
>cvs:
>
>1. once you're ready to submit, make a LIST of your files.
>2. add a tag PRE_CHECKINLABEL to ONLY those files (using your list)
>3. check in
>4. add a tag PRE_CR_CHECKINLABEL (Code Review) to ONLY those files
>5. make changes as appropriate for the CR and check in again and get CR
>approval
>6. add a tag POST_CHECKINLABEL to ONLY those files
>
>This way, you can double -j when merging those changes around based on
>the tags, and you're not relying on cvs's insane file versions, and the
>pre cr tag allows you to back a change out a lot easier. And I *think*
>the reason to only tag your specific files is because it makes it easier
>to figure out what files are changed by any given change, though I'm not
>sure that's it -- whatever it was, we had a really good reaosn for that
>policy (and I don't think it was just that some of my fellow engineers
>were idiots and I didn't trust them not to check in all of their global
>changes if they weren't using file lists).
>
>
>
It looks like a good idea for major enhancements or code
refactoring.(like tags, for instance) For those of us with less CVS
experience, could you give examples of what cvs commands are run at each
step?
Thanks,
Kevin
|
|
From: Andrew T. <ajt...@hi...> - 2005-11-27 16:46:40
|
Well, to check what's changed in your CVS do: cvs -n up U : updated in CVS M : local copy changed P : differences in local copy to CVS copy (needs to merge) C : conflict - merged into local copy - you need to search the local copy and resolve the code between the <<<< and >>>>> flags You can also check out this: http://ximbiot.com/cvs/cvshome/docs/blandy.html or http://www.cvsnt.org/manual/html/Modifying-tags.html or grab MacCVS or WinCVS which are decent GUI's for CVS. I guess I can see the benefit of doing this kind of tagging. FoFRedux is a rather small codebase (which is good - let's keep it that way) which can mean a lot more conflicts occuring with overlapping code. This may be a reason Steve M. originally kept the project to himself. Anyways, I guess you are suggesting: PRE_ADDEDTAGS PRE_CR_ADDEDTAGS POST_ADDEDTAGS as an example? Perhaps use LABELS from a marked Feature Request, Bug, Support, from Sourceforge. Make sure and put what LABEL is used in the Sourceforge bug notes therefore, you would: 1) update before any modifications (-d adds any new directories) cvs up -d 2) modify code 3) Check for what files you modified cvs -n up 2) Tag now as pre-mod cvs tag PRE_ADDEDTAGS index.php init.php 3) commit modifications cvs commit index.php init.php 4) Tag Code Review (whole repository?) cvs tag PRE_CR_ADDEDTAGS 5) Wait for others to verify modifications 6) Tag cvs tag POST_ADDEDTAGS Andy On 11/27/05, Kevin <ke...@dr...> wrote: > Benjamin Stewart wrote: > > >Do we have plans for code reviewing going forward? Like, here's my > >diff, here are comments from someone else, dev responds to comments, > >changes made, and done? > > > >Here's what I've found works really well when working with branches in > >cvs: > > > >1. once you're ready to submit, make a LIST of your files. > >2. add a tag PRE_CHECKINLABEL to ONLY those files (using your list) > >3. check in > >4. add a tag PRE_CR_CHECKINLABEL (Code Review) to ONLY those files > >5. make changes as appropriate for the CR and check in again and get CR > >approval > >6. add a tag POST_CHECKINLABEL to ONLY those files > > > >This way, you can double -j when merging those changes around based on > >the tags, and you're not relying on cvs's insane file versions, and the > >pre cr tag allows you to back a change out a lot easier. And I *think* > >the reason to only tag your specific files is because it makes it easier > >to figure out what files are changed by any given change, though I'm not > >sure that's it -- whatever it was, we had a really good reaosn for that > >policy (and I don't think it was just that some of my fellow engineers > >were idiots and I didn't trust them not to check in all of their global > >changes if they weren't using file lists). > > > > > > > It looks like a good idea for major enhancements or code > refactoring.(like tags, for instance) For those of us with less CVS > experience, could you give examples of what cvs commands are run at each > step? > > Thanks, > Kevin > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > Fofredux-devel mailing list > Fof...@li... > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > -- Andrew Turner ajt...@hi... 42.4266N x 83.4931W http://highearthorbit.com Northville, Michigan, USA idealistic technocrat Photos - http://flickr.com/photos/ajturner Travel - http://highearthorbit.com/projects/location/ |
|
From: Carlos K. <ck...@gm...> - 2005-11-23 12:36:43
|
Andy said: >Carlos, can you apply thetimestamp patch of yours? Of course, i'll do it. |
|
From: Kevin <ke...@dr...> - 2005-11-25 23:57:50
|
Carlos Kozuszko wrote: >Andy said: > > >>Carlos, can you apply thetimestamp patch of yours? >> >> > >Of course, i'll do it. > > > I thew in a change to work around mysql errors I was getting when $timestamp was empty. I only saw your patch after I made my commit. It only changes the behavior of $timestamp not $dcdate. |
|
From: Kevin <ke...@dr...> - 2005-11-27 21:48:42
|
Andrew Turner wrote: >Well, to check what's changed in your CVS do: > >cvs -n up > >U : updated in CVS >M : local copy changed >P : differences in local copy to CVS copy (needs to merge) >C : conflict - merged into local copy - you need to search the local >copy and resolve the code between the <<<< and >>>>> flags > >You can also check out this: >http://ximbiot.com/cvs/cvshome/docs/blandy.html >or >http://www.cvsnt.org/manual/html/Modifying-tags.html > >or grab MacCVS or WinCVS which are decent GUI's for CVS. > >I guess I can see the benefit of doing this kind of tagging. FoFRedux >is a rather small codebase (which is good - let's keep it that way) >which can mean a lot more conflicts occuring with overlapping code. >This may be a reason Steve M. originally kept the project to himself. > >Anyways, I guess you are suggesting: >PRE_ADDEDTAGS >PRE_CR_ADDEDTAGS >POST_ADDEDTAGS > >as an example? Perhaps use LABELS from a marked Feature Request, Bug, >Support, from Sourceforge. Make sure and put what LABEL is used in the >Sourceforge bug notes > >therefore, you would: >1) update before any modifications (-d adds any new directories) > cvs up -d >2) modify code >3) Check for what files you modified > cvs -n up >2) Tag now as pre-mod > cvs tag PRE_ADDEDTAGS index.php init.php >3) commit modifications > cvs commit index.php init.php >4) Tag Code Review (whole repository?) > cvs tag PRE_CR_ADDEDTAGS >5) Wait for others to verify modifications >6) Tag > cvs tag POST_ADDEDTAGS > > Okay. I understand it a bit better. It's all done with revision tags, but my checkins are against the HEAD branch. |
|
From: Andrew T. (nilspace) <nil...@us...> - 2005-11-27 22:21:08
|
Branches and tags are different, but related, things. Tags are used to mark a specific revision of files, or more importantly, the repository. For example, we will probably tag Release-0_2, RC-0_3, etc. THis allows Devs & Users to go and get a specific tag/release of code using the name. A Branch is like a fork in the code. A dev may want to go and work on a bunch of changes, be able to check those changes in, work with other devs, etc. But not "mess up" HEAD. Therefore, they will create a branch (BRANCH_AJAX). A branch can have it's own tags. At some point a branch can come back to the HEAD, or it can always just be a branch and you can merge files to the branch or from the branch to the HEAD. Andrew On 11/27/05, Kevin <ke...@dr...> wrote: > Andrew Turner wrote: > > >Well, to check what's changed in your CVS do: > > > >cvs -n up > > > >U : updated in CVS > >M : local copy changed > >P : differences in local copy to CVS copy (needs to merge) > >C : conflict - merged into local copy - you need to search the local > >copy and resolve the code between the <<<< and >>>>> flags > > > >You can also check out this: > >http://ximbiot.com/cvs/cvshome/docs/blandy.html > >or > >http://www.cvsnt.org/manual/html/Modifying-tags.html > > > >or grab MacCVS or WinCVS which are decent GUI's for CVS. > > > >I guess I can see the benefit of doing this kind of tagging. FoFRedux > >is a rather small codebase (which is good - let's keep it that way) > >which can mean a lot more conflicts occuring with overlapping code. > >This may be a reason Steve M. originally kept the project to himself. > > > >Anyways, I guess you are suggesting: > >PRE_ADDEDTAGS > >PRE_CR_ADDEDTAGS > >POST_ADDEDTAGS > > > >as an example? Perhaps use LABELS from a marked Feature Request, Bug, > >Support, from Sourceforge. Make sure and put what LABEL is used in the > >Sourceforge bug notes > > > >therefore, you would: > >1) update before any modifications (-d adds any new directories) > > cvs up -d > >2) modify code > >3) Check for what files you modified > > cvs -n up > >2) Tag now as pre-mod > > cvs tag PRE_ADDEDTAGS index.php init.php > >3) commit modifications > > cvs commit index.php init.php > >4) Tag Code Review (whole repository?) > > cvs tag PRE_CR_ADDEDTAGS > >5) Wait for others to verify modifications > >6) Tag > > cvs tag POST_ADDEDTAGS > > > > > Okay. I understand it a bit better. It's all done with revision tags, > but my checkins are against the HEAD branch. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > Fofredux-devel mailing list > Fof...@li... > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > -- Andrew Turner ajt...@hi... 42.4266N x 83.4931W http://highearthorbit.com Northville, Michigan, USA idealistic technocrat Photos - http://flickr.com/photos/ajturner Travel - http://highearthorbit.com/projects/location/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X