User forums > Using Code::Blocks
Preliminary documentation
Pecan:
How is svn going to allow all of us to update this document?
When someone else makes a change to (say) keybinder, svn nolonger lets me update. I have to revert my changes, update from svn, remake the changes, then update again.
Is that how it's supposed to be? If many people are hitting the same document frequently, how will this ever work?
byo:
--- Quote from: Pecan on June 14, 2007, 01:12:41 pm ---When someone else makes a change to (say) keybinder, svn nolonger lets me update. I have to revert my changes, update from svn, remake the changes, then update again.
--- End quote ---
Svn should always let you update. It will bock commit if files were changed by someone else. And usually when update is performed, svn tries to merge your local changes with the ones made on repository. This works very well in most cases. The only problem is when changes are made to the same part of code. In such situation, conflicts must be resloved manually.
So as long as files are in text form, there shouldn't be problems with commiting. Document may be also splitted into smaller files to prevent most of conflicts.
Regards
BYO
Pecan:
--- Quote from: byo on June 14, 2007, 01:31:55 pm ---
Svn should always let you update. It will bock commit if files were changed by someone else.
...
--- End quote ---
Yes, that's what I mean. How will all of us update the document at the same time?
What is the proper sequence? Make changes; update; then commit?
Or update; make changes; commit? Or what...
What is the proper response when it refuses to let you commit?
mariocup:
Hi Pecan,
I think we should split the parts of the documents in reasonable small parts (e.g. every plugin a seperate file). So if you make an update of all small files you will see the svn status. It is the same process like managing source code and that is the daily work. Perhaps we should have some developers that are "responsible/maintainer" of parts of the document, also for different languages.
As the files are splitted in small parts it will be easy to add (and to diff) documentation for a new plugin and we will only have to add an input command of this file.
Regards,
Mario
TDragon:
--- Quote from: Pecan on June 14, 2007, 02:09:38 pm ---What is the proper sequence? Make changes; update; then commit?
Or update; make changes; commit? Or what...
What is the proper response when it refuses to let you commit?
--- End quote ---
The proper sequence is "make changes; update; commit" -- or, better yet, "update; make changes; update; commit". This page in the SVN book has proven helpful to me (albeit command-line svn only is exampled). Basically svn forces you to resolve any conflicts between the code you've just created and the code in the repository before it lets you commit to the repository -- obviously a good thing. Like byo said, usually the resolution happens automatically with an update; sometimes, when svn doesn't know how to resolve things automatically, the update ends with a file or two marked as "conflicted", and you have to use TortoiseMerge or whatever to fix it up. So the proper response when it refuses to let you commit is to update, and if some files come up as conflicted, resolve them to files that are merely changed.
Hope that helps,
John E. / TDM
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version