Carl-Daniel Hailfinger wrote:
On 29.10.2009 09:52, Stefan Reinauer wrote:
I know some people will claim this hurts. But it will hurt the same way when the version number is up to 4, so we better do it now than later:
Sorry, NACK. You're right that it hurts, but does it have any benefits except a cosmetic path name change? In that case we should finally kill the /repos/ component of the path and replace it with something meaningful like /coreboot-v42.1/ or something else which says we have coreboot v1/v2/v4 in there.
My personal criteria for any patch are:
- Does it fix a bug?
Yes.
- Does it add a new feature?
No. It's an infrastructure bug fix.
- Does it make the lives of developers easier?
Yes. Because - people will ask why v4 is called v2 and we will waste time to answer. - if we go down path 2, we will finally have all utilities together again. (Something I want to see anyways), so branching and merging will become substantially easier.
(This just renames coreboot-v2 to coreboot-devel in the tree) svn mv svn://coreboot.org/repos/trunk/coreboot-v2 \ svn://coreboot.org/repos/trunk/coreboot-devel
If you really do the move, please pick the one-rename variant.
Alternatively:
(this moves all sudirectories of coreboot-v2 to trunk and wipes the coreboot-v2 directory as soon as it's empty. Then the directory hierarchy would be more similar to, e.g. flashrom)
The multi-part move makes it extremely difficult to carry any local changes forward and it needlessly complicates any history investigation (e.g. "when was this change introduced"). Besides that, you can forget diffing between revisions
Roughly your problem can be solved by:
svn diff > /tmp/my-patch.diff svn up patch < /tmp/my-patch.diff
This is a one time job, compared to the recurring pain with a scattered tree.
Stefan