Re: Things I'd like to remove from the trunk
- 2007/12/5 19:25:36
- davidl2
Can you remove the extras folder that had GiJoes code in as well?
Unless we want to put the old xoops one in for any reason?
Re: Things I'd like to remove from the trunk
- 2007/12/5 19:21:10
- marcan
Quote:
/backend.php => old rss feed link, requiring Herve's news module
/extras/theme_x2t => let's dump all the old themes
/themes/phpkaox
/themes/x2t
Oh god please do !!!! Why the hell are theses files still here !
Can you proceed to this steve ?
Re: Not commiting my own mainfile - Please help me !!!
- 2007/12/5 19:16:58
- marcan
The problem with mainfile.php is that is is a file that NEED to be versionned. It's easy to ignore file that ARE NOT versionned. But it is not the case with mainfile.php.
If I follow the previous comment, then I would need to do an SVN REMOVE on mainfile.php so then I could add it to ignore list. But then the mainfile.php would no more be present on the SVN. So this is not working.
The only thing I see is to always remember to uncheck that file for commit when we are doing an SVN commit at the root of the project....
Or am I missing something ?
GiJoe fix: Revision 16
- 2007/12/5 19:14:05
- davidl2
I've added the GiJoe fix that caused so many problems - to class/smarty/xoops_plugins/
The old version could be moved to the extras folder, and message changed to reflect this inclusion for legacy purposes?
Re: user.php
- 2007/12/5 17:43:25
- skenow
oops, found it here - http://xmtd.svn.sourceforge.net/viewvc/xmtd/branches/2.0.18-reboot/htdocs/user.php?revision=28&view=markup
user.php
- 2007/12/5 17:41:21
- skenow
Where did this little bit in user.php come from?
$config_handler =& xoops_gethandler('config');
$xoopsConfigUser =& $config_handler->getConfigsByCat(XOOPS_CONF_USER);
if ($xoopsConfigUser['allow_register'] == 1) {
$xoopsTpl->assign('allow_registration', $xoopsConfigUser['allow_register']);
}
I can't find it in xoops.svn or the xmtd.svn, but it is in the icms trunk.
Re: ImpressCMS Theme
- 2007/12/5 16:33:44
- davidl2
It would be good if whatever theme we uses, also makes use of at least one extra block positions of ICMS as well...
Re: Things I'd like to remove from the trunk
- 2007/12/5 16:31:40
- davidl2
Agreed.
And we could do with some new themes including at least one that uses the multi-block definations....
Now theres a challenge 
Only problem - we'd have to include some simple instructions to tell people how to set them up.
Things I'd like to remove from the trunk
- 2007/12/5 16:26:40
- skenow
There are files/folders in the trunk that need to be removed, either because they have no current function, or because they just need to ...
/backend.php => old rss feed link, requiring Herve's news module
/extras/theme_x2t => let's dump all the old themes
/themes/phpkaox
/themes/x2t
sound ok?
Re: ImpressCMS SVN Repository
- 2007/12/5 15:55:14
- skenow
Now that I am starting to understand svn a little more, this makes a lot of sense.
+1
Re: Not commiting my own mainfile - Please help me !!!
- 2007/12/5 15:51:07
- skenow
From the Tortoise SVN help
Quote:
B.8. Ignore files which are already versioned
If you accidentally added some files which should have been ignored, how do you get them out of version control without losing them? Maybe you have your own IDE configuration file which is not part of the project, but which took you a long time to set up just the way you like it.
If you have not yet committed the add, then all you have to do is use TortoiseSVN → Revert... to undo the add. You should then add the file(s) to the ignore list so they don't get added again later by mistake.
If the files are already in the repository, you have to do a little more work.
Move the file to somewhere safe, not inside your working copy.
TortoiseSVN → Commit the parent folder. TortoiseSVN will see that the file is missing and you can mark it for deletion from the repository.
Move the file back to its original location.
Add the file to the ignore list so you don't get into the same trouble again.
If you need to remove a whole folder/hierarchy from version control, the procedure is different again.
TortoiseSVN → Export the folder to somewhere safe, not inside your working copy.
TortoiseSVN → Delete the folder from your working copy.
TortoiseSVN → Commit the deleted folder to remove it from the repository.
Move the exported folder back to its original location in your working copy.
Add the folder to the ignore list so you don't get into the same trouble again
I have only worked with SVN/CVS a little, so I export a copy of my sandbox to my local server for testing. When I'm happy with it, I merge the changes into my sandbox copy, then commit to the repository.
Re: ImpressCMS SVN Repository
- 2007/12/5 12:49:03
- Dave_L
I can do that, but before finalizing our rules, we should probably wait until more developers have had a chance to provide feedback here.
Re: ImpressCMS SVN Repository
- 2007/12/5 11:38:46
- marcan
+1
Dave, would you have time to put those rules on a page at reboot group so it will become our "official" rules, which we could improve as the time go by.
We would make this page available publically in our soon to come wiki.
Let me know !
Re: ImpressCMS SVN Repository
- 2007/12/5 8:49:14
- Dave_L
I agree with Rules 1-3, and would like to propose another one:
- Rule #4: All committed code must be fully documented.
In part, that means that every function has a phpDocumentor-compliant header comment, which is both correct and understandable, states the purpose of the function and describes the parameters and return value. The same applies to class properties. The header comment for a function (or a class) is intended to be a "mini user manual" for the function that provides all the information needed to call that function, without having to examine the body of the function.
I suppose this won't apply to existing code that you're modifying and don't understand well enough to add missing documentation. Ideally we could review it and figure out together how to document it, but time may not permit that.
Re: ImpressCMS IRC channel
- 2007/12/5 8:36:29
- JMorris
Forgive me if I don't join you guys on IRC. I've only used it a couple times and that was over 4 years ago. I don't know enough about it or trust it enough to open my firewall up for the protocol.
You know how to reach me if there is something important you need me to help with. 
ImpressCMS Professional Services: INBOX International inc.
James Morris Online | Frolicking on the playground that is the Internet...
Re: Not commiting my own mainfile - Please help me !!!
- 2007/12/5 7:14:22
- Dave_L
I suspect this section of the SVN book may help, but I'm not sure how to apply it: Ignoring Unversioned Items
Not commiting my own mainfile - Please help me !!!
- 2007/12/5 6:51:59
- marcan
Hey guys,
I really suck at NOT committing my own mainfile. Can you help me here. What is the best way to avoid that ?
Also, do you guys have some problems sometimes with the cache folder when SVN updating or SVN commiting.
Thanks !
Re: ImpressCMS SVN Repository
- 2007/12/5 6:35:07
- marcan
Thanks Dave, excellent link.
I suggest every one involved in coding should read this bes practice summary.
About branching
So I now realize that XOOPS was using the Always branch system and I understand now that it has pros, but I feel more cons...
I very like the "Branch-when-needed" system :
- Users commit their day-to-day work on /trunk.
- Rule #1: /trunk must compile and pass regression tests at all times. Committers who violate this rule are publically humiliated.
- Rule #2: a single commit (changeset) must not be so large so as to discourage peer-review.
- Rule #3: if rules #1 and #2 come into conflict (i.e. it's impossible to make a series of small commits without disrupting the trunk), then the user should create a branch and commit a series of smaller changesets there. This allows peer-review without disrupting the stability of /trunk.
Can we all agree on this ?
ImpressCMS is a multi-language content management system for the web. It is community-built, an open source project and based on the common web technologies of PHP and MySQL.
More information
