Sorry to top post here, but:
When we introduced locking, didn't we do a little trick to ensure we
were using only the right (locking) clients/servers to access a
repository? Can't we do the same trick on the file:// and server
levels?
What we did (I think): access the repository with the any current
format. When locking is requested: create the locks table and replace
the format file with a specific number. Older clients now can't access
the repository anymore, which is exactly what we want.
I think the same could apply here: as long as there hasn't been any
merge-tracking done on the repository, it's fine to allow all clients
access. After merge tracking has been introduced, older clients should
be rejected on a libsvn_fs_* level. We can do that with the right
format number.
bye,
Erik.
On 2/14/07, Daniel Rall <dlr@collab.net> wrote:
> 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?
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 14 22:47:37 2007