Re: Keeping the changelog |
by Dave_L on 2007/12/7 15:47:54 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 |
Re: Keeping the changelog |
by nekro on 2007/12/7 12:17:16 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!... |
Re: Keeping the changelog |
by skenow on 2007/12/7 11:42:07 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. |
Re: Keeping the changelog |
by Vaughan on 2007/12/7 11:19:16 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. |
Re: Keeping the changelog |
by Dave_L on 2007/12/7 11:06:13 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) |