Login | Register
My pages Projects Community openCollabNet

Discussions > users > fsvs error message "Couldn't find a working copy with matching base"

fsvs
Discussion topic

Hide all messages in topic

All messages in topic

RE: fsvs error message "Couldn't find a working copy with matching base"

Author "Miller, Hugh" <HughMiller at chevron dot com>
Full name "Miller, Hugh" <HughMiller at chevron dot com>
Date 2011-08-01 11:21:56 PDT
Message Hi Phil,

Philipp Marek wrote:

> Is it possible that the new automounter changed the name of the mounted
> directories, eg. from /media/usb-stick to /media/sdb1 or something like
> that?
> This could explain the change in behaviour.
>
> The _base symlink might just be working because the automounter
> provided
> aliases/symlinks for alternative names, too?
>

The text of the path in the symlink _base -> ... did not change, but the "real" mount locations did change at least as far as the text of the paths goes. Originally the mount was under /.automount/... but the new implementation has a completely different looking "real" path, implemented by a special set of folders under "/" on all machines.

Thanks again,
Hugh

Re: fsvs error message "Couldn't find a working copy with matching base"

Author pmarek
Full name P.Marek
Date 2011-08-01 10:33:49 PDT
Message Hello Hugh!

On Monday 01 August 2011 Miller, Hugh wrote:
> > Could you please do a
> >
> > realpath $FSVS_CONF/*/_base
> >
> > and
> >
> > fsvs info -d
> >
> > in the WC root, and one directory below, and send me the results?
> > (Privately, if you prefer.)
>
> Unfortunately I don't think I can meaningfully do those checks.
Is it possible that the new automounter changed the name of the mounted
directories, eg. from /media/usb-stick to /media/sdb1 or something like that?
This could explain the change in behaviour.

The _base symlink might just be working because the automounter provided
aliases/symlinks for alternative names, too?


> To get things working, after a bit of experimenting with a small test
> repository, I removed the conf folder completely, then re-ran "fsvs urls
> ...". I was then able to run "fsvs sync-repos" and everything came back
> (looks normal, so far). I did this with both repositories.
Well, yes, that's the normal setup/recovery procedure.

 
> There is now no _base symlink. I am using fsvs 1.2.2 and svns 1.6.11.
Yes, that's gone with the last few versions - it just gave problems with
"find" and other tools.


Regards,

Phil

--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

RE: fsvs error message "Couldn't find a working copy with matching base"

Author "Miller, Hugh" <HughMiller at chevron dot com>
Full name "Miller, Hugh" <HughMiller at chevron dot com>
Date 2011-08-01 08:59:08 PDT
Message Hi Philipp

> Could you please do a
>
> realpath $FSVS_CONF/*/_base
> and
> fsvs info -d
>
> in the WC root, and one directory below, and send me the results?
> (Privately, if you prefer.)

Unfortunately I don't think I can meaningfully do those checks.

To get things working, after a bit of experimenting with a small test
repository, I removed the conf folder completely, then re-ran "fsvs urls
...". I was then able to run "fsvs sync-repos" and everything came back
(looks normal, so far). I did this with both repositories.

There is now no _base symlink. I am using fsvs 1.2.2 and svns 1.6.11.

Thanks, Hugh

Re: fsvs error message "Couldn't find a working copy with matching base"

Author pmarek
Full name P.Marek
Date 2011-07-31 09:56:25 PDT
Message Hello Hugh,

please excuse the long delay.


> Two fsvs working trees which I have previously had no problems with now
> no longer respond to fsvs info, status etc.. I get the message "couldn't
> fine working copy with matching base".
Hmmm ... strange.


> What might be the cause of this ? Would sync-repos fix the problem ?
No, not directly; if there's no base found the URLs are unknown, too.


> I have examined the working trees, the FSVS CONF and WAA areas for each
> case and don't see any changes of any kind to the files and directories
> since the last successful commit. In each case, there is a _base link
> below FSVS_CONF which is still correct.
...
> The only thing I can think of that has changed since things were last
> working is the automounter.
...
> I notice now that if I follow the _base link under CONF to the working
> area tree, which is in an automounted folder, then do "pwd" I get
> $FSVS_CONF/.../_base. I am not sure if this is new behavior since the
> AMD change. I am not sure if this different than it was before the
> automounter change. The link is valid in the sense that cd works,
> expected files are seen etc.
Well, yes. It's good to know that.
FSVS determines the CONF and WAA directory by the full pathname - which will be
different if reached via symlinks, so it's normal that it won't work from there.


Could you please do a

    realpath $FSVS_CONF/*/_base
and
    fsvs info -d

in the WC root, and one directory below, and send me the results?
(Privately, if you prefer.)


Regards,

Phil

fsvs error message "Couldn't find a working copy with matching base"

Author "Miller, Hugh" <HughMiller at chevron dot com>
Full name "Miller, Hugh" <HughMiller at chevron dot com>
Date 2011-07-25 09:21:45 PDT
Message Hi Phil,

 

Two fsvs working trees which I have previously had no problems with now
no longer respond to fsvs info, status etc.. I get the message "couldn't
fine working copy with matching base".

 

What might be the cause of this ? Would sync-repos fix the problem ?

 

I have examined the working trees, the FSVS CONF and WAA areas for each
case and don't see any changes of any kind to the files and directories
since the last successful commit. In each case, there is a _base link
below FSVS_CONF which is still correct.

 

The only thing I can think of that has changed since things were last
working is the automounter.

 

I notice now that if I follow the _base link under CONF to the working
area tree, which is in an automounted folder, then do "pwd" I get
$FSVS_CONF/.../_base. I am not sure if this is new behavior since the
AMD change. I am not sure if this different than it was before the
automounter change. The link is valid in the sense that cd works,
expected files are seen etc.

 

Many thanks for any light you can shed on this!

 

-

Hugh Miller
Attachments
Messages per page: