[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: merge tracking: rejecting commits from svn clients < 1.5

From: Daniel Rall <dlr_at_collab.net>
Date: 2007-02-14 22:41:00 CET

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.