> ----- Original Message -----
> From: "Branko Čibej" <brane@xbc.nu>
> > >
> > > Right now subversion doesn't provide a function to
> > > get the version of a repository (or I havent' found
> > > one). I already checked the mailing list and the issue
> > > tracker but found nothing.
> >
> > svn_repos_open will check the repository version. However, up to now, we
> > have never changed the version number: the schema changed too many
> > times, and we do have a pre-1.0 compatibility policy documetned.
>
I know it's documented. The only problem is that if you
forget to check the versions yourself neither the client
nor the server will tell you that they're incompatible.
>
> > > I would like that both server and client would exchange
> > > those version information on connect. That way
> > > both server and client could check if they are still
> > > compatible and error out if they are not (I guess it will
> > > always be the newest versioned part (server or client) which
> > > will know if it's compatible or not).
> >
> > I think it might be a bit more complicated than that. Server and client
> > should exchange a list of capabilities, like they do in ra_svn.
>
I'm not familiar with the ra_svn layer. But you're suggestion is
much better.
>
> > > This would make problems with incompatibilities non-existent
> > > because a clear error message (e.g. "you need to update your
> > > client to access this server") will prevent the user from
> > > corrupting something in the repository/working copy.
> >
> > Well, that wouldn't make incompatibilities non-existent. :-)
> > I also don't believe it's viable before 1.0, or at least until our final
> > FS schema changes go in. Right now, the compatibility rule we have (one
> > version etither way) is the best we can do, IMHO. Server admins should
> > just make sure that people are using new enough clients.
>
And that's exactly the problem. It's easily done inside a LAN where
the admin has control over the clients. But imagine a public
repository where you don't have that control (e.g. sourceforge.net).?
Personally I don't think that this should be done after 1.0 but before
since this feature is especially useful during the development phase
of subversion where changes to client/server are more likely than
after 1.0.
>
> > > Also, for local repositories (no server) the client should be
> > > able to check with which version the db was built and
> > > especially with which version of the berkeley db it
> > > was built and at least warn the user if those don't match.
> >
> > This is already done, both at compile time and at run time. the FS layer
> > will error out if it's running under a different BDB version than it was
> > compiled against.
>
Sorry, didn't know that.
>
> > > Maybe create a file with those version numbers in it
> > > when calling svn_repos_create() which could be read out?
> >
> > The BDB version numbers? But that's entirely the FS's business, isn't
it?
>
Sure, you're right. Do you know if the actually do?
>
> > > I guess this file would then have to be updated when
> > > doing an svnadmin dump/load?
> >
> > I don't understand this. We already have a dump format version in the
> > dump file. The dump format is theoretically independent of the FS
schema.
>
what I meant is if a file with a version is placed in the repository and you
do a svnadmin dump/load to update the repository to a newer version then
the file with the version number in it should be updated.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 26 22:41:30 2003