6/12/2007 5:02:34
|
---|
|
Keeping the changelogWe'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.
|
6/12/2007 5:26:46
|
---|
|
Re: Keeping the changelogI rather like how Nekro arranged them - separating fixes, etc - so it is easier to read.
|
6/12/2007 10:55:45
|
---|
|
Re: Keeping the changelogCitaat:
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 ? |
6/12/2007 16:18:09
|
---|
|
Re: Keeping the changelogYesterday, 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. |
7/12/2007 10:37:29
|
---|
|
Re: Keeping the changelogOk, anyone has something to suggest so we don't have this problem ?
|
7/12/2007 11:06:13
|
---|
|
Re: Keeping the changelogBefore 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) |
7/12/2007 11:19:16
|
---|
|
Re: Keeping the changelogyes, 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.
|
_________________
Live as if you were to die tomorrow, Learn as if you were to live forever The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together! |
7/12/2007 11:42:07
|
---|
|
Re: Keeping the changelogIndeed, 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. |
7/12/2007 12:17:16
|
---|
|
Re: Keeping the changelogI 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!...
|
7/12/2007 15:47:54
|
---|
|
Re: Keeping the changelogFor 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 |