Re: [Aglets-users] [Aglets-developer] the new logging subsystem

[Luca F. <cat...@us...>]

On Thursday 19 July 2007 Thomas Herlea's cat, walking on the keyboard, wrote:
> 1. mv .classpath .cp
> 2. mv .project .pr
> 3. cvs remove .classpath .project
> 4. cvs commit -m "Not portable enough." .classpath .project
> 5. mv .cp .classpath
> 6. mv .pr .project
> 7. echo .cvsignore > .cvsignore
> 8. echo .classpath >> .cvsignore
> 9. echo .project >> .cvsignore
> 10. # remove everything from classes/ except its CVS/ subdirectory
> 11. cvs update -P
> 12. mkdir classes
> 13. echo classes >> .cvsignore
>
> Steps 1-2 "save" the two local files.
> Steps 3-4 remove them from the repository.
> Steps 5-6 "restore" the files locally.
> Step 7 creates the .cvsignore file and instantly makes it "invisible" to
> your local cvs client. That is, even though the cvs client will see
> that '.cvsignore' is not under version control, it will not bother you
> about adding it to the repository.
> Steps 8-9 make the two local files also "invisible" to the cvs client.
> Steps 10-11 convince your local CVS that 'classes/' is not under version
> control any more.
> Step 12 makes 'classes/' available for your Eclipse again.
> Step 13 makes 'classes/' also invisible to the cvs client.


 Thomas, I think now the cvs is ok. I've deleted the .project and .classpath > 
file and also .cvsignore should not be committed. Can you confirm is this 
 ok? 

> Don't we lose flexibility that way in case the class is moved to another
> package or if users will want to replace the class with their own? Is this
> change made for performance reasons? Is it for uniformity with the rest of
> the source code? I'm just guessing, so an official explanation would be
> welcome in this case, too.
>


The main reason was uniformity, while I was thinking that the reflection could 
improve the code for refactoring or even inheritance. I was already changing 
the code and today I finished it and committed.

Luca