On Wed, 14 Feb 2007, Blair Zajac wrote:
> Malcolm Rowe wrote:
...
> >But, really, what are we trying to fix here? The problems caused by
> >someone committing using a non-merge-tracking client? Assuming you have
> >any kind of post-commit review, you should spot the problem immediately.
>
> That's assuming you have a well run organization. I am aware of larger
> organizations where many people don't know how to use svn well or where
> there aren't reviews and then only after the fact, do you have to clean
> up. I would rather be safe than sorry. Better some up front work than
> clean up a mess later.
Indeed. I share Blair's concerns here. I know this will be a
complaint from my customer base.
> >Even if not, once you've spotted the problem (I'm assuming the symptoms
> >would typically be a repeated merge, so you'd probably get a conflict
> >merging to the branch), you can just fix it using the 'svn merge'
> >equivalent of svnmerge.py's --record-only option.
> >
> >You can also tell people "Don't do that". I find that frequently works
> >a lot better than constructing a technical solution.
>
> Again, work after things are messed up. I would rather just have an
> easy solution that I don't have to think about it later.
>
> I don't see it hard having the svn client provide an environmental
> variable that the pre-commit script can look for the existence of.
Well, Kamesh pointed out that it is actually quite hard. How can the
repository differentiate "normal"-commit vs. commit-of-merge?
- application/pgp-signature attachment: stored
Received on Wed Feb 14 22:41:21 2007