Keeping the changelog

We've already had some collisions on committing changes and the changelog is suffering the most. We need some sort of agreement on how to handle this so we keep this from getting too crazy.

I rather like how Nekro arranged them - separating fixes, etc - so it is easier to read.

Quote:
Not sure I follow you steve but one thing is for sure. Everytime we add a feature of fix a bug, we need to a line in the changelog and the commit.

Is this what you meant or is it something else ?

Yesterday, I committed changes in revision 14, including updating the changelog. Later, young-pee committed revision 17, including changes to the changelog, which wiped out my changes to the changelog. I updated my sandbox and made another commit, revision 18, again with the appropriate entries in the changelog. Revision 19 reverted to revision 17, going back to a previous version of the changelog.

The changelog will be the most edited file in the repository and we need a process to make sure all the changes get recorded with every revision.

Ok, anyone has something to suggest so we don't have this problem ?

Before committing the new change log, did you update your working copy from the repository? I thought that SVN had the ability to deal with this kind of issue (people making different changes to the same file).

References:
Basic Work Cycle
Resolve Conflicts (Merging Others' Changes)

yes, i made it a practice, that before i even do any committing I always do an update of my local svn repository beforehand, and then merge my local changes/edits into the freshly updated version, then I commit my changes.

Indeed, I did update my changelog from svn just before committing the other files. But, if even one person doesn't, the problem occurs.

I didn't know if there was something else that could be set for the changelog to enforce more careful commits to it.

I have to say sorry... i was working at the same time than skenow and at the same time i was making some mistakes in the code (SORRY SKENOW!!!!) ... i think that we keep going in the same way with the changelog... i just make some mistakes in that moments... sorry again boys!...

For a frequently modified file such as the changelog, a safety measure could be to lock the file before updating your working copy from the repository.

This wouldn't help with the case in which someone forgets to update before committing. But it would help in the following scenario:

1. Person X updates.
2. Person Y updates.
3. Person Y commits.
4. Person X commits.

If Y locked the changelog before doing the update, then X would be unable to commit the changelog. (I think that's how it works.)

Locks are only advisory. If someone locks a file and forgets about it, someone else can unlock it, but it requires an extra step.

Reference:
Locking