On Mon, 16 Jan 2006, Julian Foad wrote:
> If someone could briefly explain how SVK causes this misordering,
> without me knowing anything about SVK, that might be helpful.
A user's personal svk repository is really just a subversion repository,
and svk accesses it using the subversion perl bindings. svk allows you
to mirror remote subversion repositories to your local svk repository.
Each revision in the remote svn repository becomes a revision in
the local svk repository, but svk adds some extra properties for its
own purposes. Whenever you ask svk to sync the mirror, you will be
appending some old commits (copied form the remote repository) to your
local repository. The old commits may have svn:date properties that
are older than some other commits in (other subtrees of) your local
repository.
The above description deals with pulling changes from a remote
repository to a local repository. Pushing changes from a local
repository to a remote repository can also happen, but I am not sure
what svk does with the svn:date properties in that case.
> Is it just that SVK stores a sequence of changes locally and then
> later commits them to the (master) Subversion repository but alters
> "svn:date" to the locally stored value? If so, that's logically
> just like the "svnadmin load" situation, appending to the present
> repository a series of old commits. We'd have to decide how to handle
> that situation anyway (see below).
Yes, the date issues with svk mirrors are essentially the same as with
the "svnadmin load" situation.
> >If we're going to have two separate types of date props, some for the
> >original commit and some for the commit to this repos, then how do
> >you tell the -r flag which one you're concerned about?
>
> I don't envisage "-r{DATE}" operating on anything but "svn:date" which
> is (in my proposal) guaranteed ordered. Any other date properties
> (e.g. "original" commit dates to previous repositories, which may be
> multiple) are just more metadata, and if you want special facilities
> for searching them, that's a separate enhancement request, like the
> extended property-search revision-set facility that I mentioned
> afterwards.
When I mirror a remote repository, commits spread over several years in
the remote repository can end up spread over a few minutes in the local
mirror. If -r{DATE} can't do what I want, then I'd like some equally
convenient syntax to refer to the original dates.
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 16 09:17:17 2006