This project is read-only.

SubFox Features

Feb 13, 2009 at 2:57 PM
Hey Dale & Dave,

A couple of things I mentioned to you about Subfox that you wanted me to remind you of and a couple of new ones. 

1. A setting to force a compile before a checkin that rejects any code that won't compile.

2. A configuration option to strip comments on check in.
a. Strip comments that begin with a specified prefix - default *!*
- This is so when developers comment out old code, refactor it or whatever, then test, it gets removed from the repository on checkin. That would be a sweet feature in terms of code cleanup and time savings. 
b. Stip comments where a date older than a certain number of days is contained in the comment.
- This one would be more difficult. I basically want to auto-eliminate modification history that's older than a specified number of days.

Feb 15, 2009 at 4:20 PM
as a developer.. usualy when i comment out code i do so because i still need it there .. if i don't need it anymore (then or later) i'll remove it myself .. having the subfox remove it autmaticaly is a big no for me, but as long as this is controlled from a checkbox or something is ok, as log as its off by default ;)
Feb 20, 2009 at 4:48 PM
I agree it should be a configuration option, but saying you need code that you've commented out is sort of an oxymoron. At any rate, if code that's been commented out is deleted on check-in, it's not lost, it's still in the repository, it's just no longer cluttering up production code. 
Feb 23, 2009 at 5:03 PM
That's another thing :)

I was referring to one situation where i change a few lines of code with something elese but i leave them behind (commentd) in case something goes wrong, for referrence, for someone else that has to take note of the change and do the cleanup, or whatever. And of course i'd really wouldn't like for all the comments that documents the code - like descriptions of specific algorithms, or paramers doumentation -  to dissapear.

In conclusion i'd love to have a choice in the matter :)
Jan 19, 2010 at 5:35 AM

The re-compile feature is now in place (see release 1.2.108).  I understand the intent is to detect compiler errors, but since I don't know how to do this, I merely re-compile the files selected to upload, and abort the process if an ERR file is created.  The timing of the event is critical since programmers are expected to have some work ongoing while other changes are ready to upload.  Only the files they claim are ready should be recompiled, and only after the encoding is complete.

I have not yet addressed the 2nd request -- automatic comment removal -- which plainly goes into the realm of personal tastes.  I think this can be accomodated with properly placed hooks in the core software, enabling Mike to easily develop an add-on class to do the comment purging with his own custom code.

Jan 25, 2010 at 8:26 AM

I think automatic comment removal in not a good idea in general, and where needed is can be solved with hooks.

Even a configuration option is dangerous because if checked accidentally it could delete important code and comments.

As a developer when I put some comments in code (or leave commented code) is because I want to read it later or I want others can read it later!

Mar 15, 2010 at 2:19 PM

Just wanted to add my two cents. I aggree with amariottini and others that automatic comment removal is unnecessary and I feel it is really out side of the scope of source control although such hooks should be available either within an IDE or whatever build environment to help automate stuff when it is necessary.

Mar 15, 2010 at 6:14 PM

Just to wrap up the discussion about comment removal...

There will NOT be a built-in feature to automatically remove comments, but there WILL be a method
to write-your-own using hooks or sub-classes.

I am thinking of writing such a module to test the capabilities and to demonstrate the techniques...
and of course to fulfill Mike Feltman's request.

For the record -- I agree with Mike that removing comments is important because large teams need to have
ONLY meaningful comments.  Programmers often comment old code temporarily and rewrite whole blocks. 
By the time they are done (and ready to save to the repository) those commented code lines should be gone. 
Worried they will be lost forever?  This is SubVersion -- the system for guaranteeing that never happens. 
Using SubVersion means leaving behind the old ways; we no longer need to carry baggage.

Apr 6, 2010 at 2:57 AM

And I would also like to add that normally when working with text based source code you would code review all your changes before you make a single meaningful atomic commit meaning that it is very simple to remove such comments and polish up the code a bit before committing your change. With FoxPro I can see why this isn't inherently obvious because of the nature of the binary files. It's also possible in subversion to place hooks on the server that can reject commits that don't conform to whatever conventions you decide. In our project we generally like to ensure that the project compiles but it would also be nice to run tools on a .NET project such as FxCop or any other type of static analysis. It would not be unreasonable to implement a simple server side hook that rejects commits that contain code comments that don't follow a particle convention. In my opinion I always prefer assistance for automated tools but get nervous about tools that want to modify my code even if it's a tool I wrote myself.