David,
thanks for your answer.
> How can you tell if the code has been reviewed? Is this done via a
> property to be set on the file or directory?
Yes. Every changed/added file should have review:status set to OK and review date to day of review. In other words: every file should have "MM" (or "A")status and review:status == OK. The transaction to main trunk won't succeed unless this is true. So, with this kind of checking, I can let any developer do the commit. (even if developer does propset on a file itself, this is fine, the transaction will succeed)
> You should lock down the trunk of your tree except for your team and
> maybe trusted team leads. No one can put files on the trunk except for
> you and these trusted agents. After a successful code review, you can
> copy the files from the branch to the trunk. This could be done via a
> client script. "svn copy" doesn't need a working directory checked
> out, so the operation is pretty simple, and can easily be done in a
> script.
How? Please explain how can I copy changes from one branch to the trunk easily.
As far as I know this can only be done with:
- switch working copy from branch to main trunk
- followed by merge changes from branch to working copy
- commit to the main trunk
The main problem is 'merge' command, because I have to specify revision number.
Is there any magic command to do:
- switch + merge in one svn command?
... so that I don't have to specify any revisions. SVN already knows everything. If I have a working copy mirroring the head of the branch, then this command would simply leave all sources as they are and relocate working copy to main trunk. Now, all I have to do is update and commit, which is simple operation. I have tryed switch --relocate, but it doesn't work this way, why? I don't see any side effect with such a command. Do you? This would simply be a handy shortcut.
If you know the svn internals... can you make an estimate how much effort is needed to implement this command (for example: svn switch --keep-changes)?
> BTW, it is possible (although very difficult) to do what you want, but
> it would take a second transaction to do this. And, it would leave the
> developer's machine in an out-of -snyc with the state of the source
> archive. It is not recommended to modify a commit transaction during a
> commit.
OK, I will forget about this scenario. It doesn't have to be this way. In fact I will use any scenario as long as:
- no scripting on client side by developers (not all have scripting posibility on their machine)
- any kind of scripting on repository hooks are possible
- reviewers can run scripts on client side if needed (reviewers all have scripting)
- inside the trunk a developer should be the author of commit, not the reviewer (this is optional)
I appreciate your answers.
Zoran
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 1 23:49:53 2005