Re: wc format version bump for file externals?

On Tue, Jun 10, 2008 at 09:43:16AM -0500, kmradke_at_rockwellcollins.com wrote:
> Stefan Sperling <stsp_at_elego.de> wrote on 06/10/2008 09:10:41 AM:
> > On Tue, Jun 10, 2008 at 08:52:23AM -0500, kmradke_at_rockwellcollins.com
> wrote:
> > > The biggest problem is users that use multiple clients. Think of a
> > > windows user that has TortoiseSVN, Subclipse, and the command line
> > > utils installed. They must be smart enough to upgrade all at the
> > > same time.
> >
> > Or just not use the same working copy with different clients
> > written against mismatching versions of the svn API.
>
> We have some projects with 40G+ working copies. Multiple copies
> is not always an option. (Luckily these are not recommended
> or the norm.)

I see :(

And I bet the people who created such ridiculously large working
copies won't be willing to change their way of working, right?
Or they might even be that large for technical reasons. But still,
I think this use case may be a bit outside of what Subversion is
trying to offer.

> > If people really want to use so many different clients all
> > at once with the same working copy, then they need to deal
> > with the pain this can involve. If you tell your non-technical
> > users to do this as an admin, then you need to deal with it.
>
> I unfortunately do not have a lot of control how projects
> combine and use the clients. I can't stop them from shooting
> themselves in the foot, but I usually have to cleanup afterwards.

That is bad, but it's really more of a social problem than
a technical one. As such, I don't think it can be really fixed
by changing Subversion. There are simply too many ways people
can shoot themselves in the foot :)

> > I'd be surprised if "not supporting working copy format bumps"
> > was a design goal for wc-2.0.
>
> "Better interoperability between working copy formats" would be a
> nice design goal. There is no reason a working copy change needs
> to require incompatibility with old clients, that is just one part
> of the current design (that can hopefully be improved.)

Yes, that's a desirable goal. I like the suggestion made by Marc
Haisenko in another follow-up to your post. I'd need to
spend much more time to think about it than I can afford right now
before deciding whether it's feasible, though.

Stefan