You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Joachim Durchholz <jo...@durchholz.org> on 2007/11/20 13:19:25 UTC
Exporting with externals doesn't work
Hi all,
I'm exporting from a directory with several svn:externals definitions.
If I do this with TortoiseSVN, I get the external subdirectories.
If I do this with the Win32 packages built against Apache 2.2 from
svn.tigris.org (http://tinyurl.com/yqjfbm), I do not get the external
subdirectories.
After stripping down with the problem still reproducing, this is the
command line:
-- snip --
svn export --force "/Eigene Dateien/Berufliches/CMN/DKV/tp_aktivsystem"
-- snip --
The response is
-- snip --
Export abgeschlossen.
-- snip --
i.e. "Export completed", no error messages. The exported directory has
this directory listing:
-- snip --
D:\Eigene Dateien\Berufliches\CMN\DKV\tp_aktivsystem>dir
Datenträger in Laufwerk D: ist BACKUP
Datenträgernummer: 6853-8C1B
Verzeichnis von D:\Eigene Dateien\Berufliches\CMN\DKV\tp_aktivsystem
03.08.2007 13:09 <DIR> .
03.08.2007 13:09 <DIR> ..
03.08.2007 13:10 <DIR> custom
25.09.2007 11:15 6.619 export.php
31.08.2007 20:21 <DIR> include
13.08.2007 04:00 1.422 index.php
31.08.2007 20:21 <DIR> interface
31.08.2007 20:22 <DIR> layout
31.08.2007 20:22 <DIR> lib
11.09.2007 08:57 3.658 pdf_output.php
06.09.2007 05:47 2.635 pdf_skala.php
24.10.2007 12:18 <DIR> plugins
4 Datei(en) 14.334 Bytes
8 Verzeichnis(se), 6.461.101.056 Bytes frei
-- snip --
and these externals definitions:
-- snip --
D:\Eigene Dateien\Berufliches\CMN\DKV\tp_aktivsystem>svn propget
svn:externals
include svn+ssh://192.168.1.170/srv/svn/projekte/TP/TurnierPro/include
interface svn+ssh://192.168.1.170/srv/svn/projekte/TP/TurnierPro/interface
layout svn+ssh://192.168.1.170/srv/svn/projekte/TP/TurnierPro/layout
lib svn+ssh://192.168.1.170/srv/svn/projekte/TP/TurnierPro/lib
plugins svn+ssh://192.168.1.170/srv/svn/projekte/TP/TurnierPro/plugins
-- snip --
(Strangely enough, svn list returns "svn: Kann Tunnel nicht erzeugen:
Das System kann die angegebene Datei nicht finden.", i.e. "can't create
tunnel: the system cannot find the file given". Not sure whether that's
related or not. Though I'm somewhat mystified by the wording: how does
the existence or nonexistence of a file relate to the ability to create
a tunnel?)
This is what I get in the export directory (that is, everything that I
expected except the external directories):
-- snip --
D:\Eigene Dateien\Berufliches\CMN\cmn\export\DKV\tp_aktivsystem>dir
Datenträger in Laufwerk D: ist BACKUP
Datenträgernummer: 6853-8C1B
Verzeichnis von D:\Eigene
Dateien\Berufliches\CMN\cmn\export\DKV\tp_aktivsystem
20.11.2007 13:42 <DIR> .
20.11.2007 13:42 <DIR> ..
20.11.2007 13:42 <DIR> custom
25.09.2007 11:15 6.619 export.php
13.08.2007 04:00 1.422 index.php
11.09.2007 08:57 3.658 pdf_output.php
06.09.2007 05:47 2.635 pdf_skala.php
4 Datei(en) 14.334 Bytes
3 Verzeichnis(se), 6.461.101.056 Bytes frei
-- snip --
What's happening?
Is this a bug?
Or am I stupidly misunderstanding something obvious?
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Exporting with externals doesn't work
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 22, 2007, at 01:55, Joachim Durchholz wrote:
> Ryan Schmidt schrieb:
>>> So how about *client-side* hook scripts? Have a parameter --hook-
>>> dir for the SVN client. With a hook for checking whether a given
>>> file should be exported at all, and a hook for munging the
>>> contents of a file (possibly even before the file is written to
>>> disk: piping the file contents to stdin of the hook script would
>>> suffice).
>> Client-side hooks are not available, and probably never will be.
>> There are about a zillion threads in the mailing list archives if
>> you'd like to review them. Basically, it's a security issue to
>> allow code that someone committed to the repository to be run on
>> the client. Not to mention that it's very difficult to write a
>> script that works properly on all possible client environments,
>> given the poor scripting support built into Windows for example.
>> And what you're asking for -- the ability to tell the repository
>> what to send and not to send -- goes even further.
>
> The scripts would live on the client side, of course. IOW selecting
> the right set of hooks would have to be a command-line option of
> the client.
>
> I think the real work would be adding a hook in the protocol. I.e.
> when exporting, the SVN server would have to ask the client whether
> a specific file is actually needed before sending it.
I have a feeling you wouldn't get any support for such a feature from
the developers. This is a case where the svn client is insufficient
for your needs, so you would be told to go write your own client
program using the language bindings, which exist for most any language.
>> Hey, actually, if that's all you want, couldn't you just ask the
>> repository for a list of files first, and then only request the
>> ones you actually want? You may have to dig into the APIs, like
>> the Perl API for example, to do this optimally.
>
> Hm... well, yes, that would be an option.
> This is a PHP shop (urk), so I'd probably do an svn --xml list and
> parse the output (PHP does come with an XML parser, so I'm lucky
> here).
> ... speaking of svn list, it doesn't work either. So for the
> moment, I'm stuck with post-hoc file filtering. Not optimal, but I
> can live with that.
I'm primarily a PHP programmer too. You may want to look into this:
http://pecl.php.net/package/svn
Language bindings should be faster than running command line programs
and parsing output. But I haven't tried to use these PHP SVN bindings
yet. I ran into problems with the first version, but maybe this one's
better, or maybe I was doing something wrong before.
What do you mean "svn list [...] doesn't work"?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Exporting with externals doesn't work
Posted by Joachim Durchholz <jo...@durchholz.org>.
Ryan Schmidt schrieb:
>> So how about *client-side* hook scripts? Have a parameter --hook-dir
>> for the SVN client. With a hook for checking whether a given file
>> should be exported at all, and a hook for munging the contents of a
>> file (possibly even before the file is written to disk: piping the
>> file contents to stdin of the hook script would suffice).
>
> Client-side hooks are not available, and probably never will be. There
> are about a zillion threads in the mailing list archives if you'd like
> to review them. Basically, it's a security issue to allow code that
> someone committed to the repository to be run on the client. Not to
> mention that it's very difficult to write a script that works properly
> on all possible client environments, given the poor scripting support
> built into Windows for example. And what you're asking for -- the
> ability to tell the repository what to send and not to send -- goes even
> further.
The scripts would live on the client side, of course. IOW selecting the
right set of hooks would have to be a command-line option of the client.
I think the real work would be adding a hook in the protocol. I.e. when
exporting, the SVN server would have to ask the client whether a
specific file is actually needed before sending it.
> Hey, actually, if that's all you want, couldn't you just ask the
> repository for a list of files first, and then only request the ones you
> actually want? You may have to dig into the APIs, like the Perl API for
> example, to do this optimally.
Hm... well, yes, that would be an option.
This is a PHP shop (urk), so I'd probably do an svn --xml list and parse
the output (PHP does come with an XML parser, so I'm lucky here).
... speaking of svn list, it doesn't work either. So for the moment, I'm
stuck with post-hoc file filtering. Not optimal, but I can live with that.
Thanks for all the help!
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Exporting with externals doesn't work
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 21, 2007, at 04:37, Joachim Durchholz wrote:
> Ryan Schmidt schrieb:
>
>> I believe the bug occurs any time you try to export from a working
>> copy (regardless of what protocol you used to check the working copy
>> out with), and I believe the bug does not occur if you try to export
>> from a repository URL (again, regardless of the protocol). But I have
>> not tested every protocol.
>
> OK, I'll have to try it out.
>
> Thinking about alternatives:
>
> Since the script is doing a rollout, which means walking the
> directory and munging files anyway: is an exported tree equivalent
> to a checked-out repository with the .svn directories removed?
Yes, that's exactly what export does: it removes the .svn directories.
> In that case, I could simply copy the repository tree and skip the
> unwanted files (i.e. .svns and some other stuff that I'm currently
> stripping after the export). This would also speed up the process
> because the repository contains some large binary files that aren't
> going into production anyway (test data and such).
>
> Another alternative: wait for 1.5.
> Should I hold my breath?
No; there's no ETA yet on when 1.5 will be done. "It'll be done when
it's done" is the common response I've seen.
> P.S.: Re CCing and reply-to headers: Thunderbird isn't smart enough
> to properly react to mailing-list headers. I've been considering
> dropping TB for a while now, it's just that I haven't come across a
> satisfactory alternative yet...)
>
> P.P.S.: I think that "export from the respository and have some
> file munging" scenario is quite common. That's not really
> attractive though: e.g. when rolling out for the customer, you
> don't want to first export several megabytes of versioned test data
> just to delete them afterwards; you'd want to filter them even
> before they get transmitted from the repository to the rollout
> directory.
I approach it differently: I structure my projects such that
everything that should be deployed is in one directory in the
repository. Other data which is needed during development but not
during deployment is in a separate directory. For deployment, just
export the deployment directory.
> My knee-jerk reaction was "use a hook script then"; however, since
> every hook script must serve all needs, this means that you have to
> coordinate closely that the export will do something differently
> depending on whether the checkout/export is for programming, for
> testing, or for rollout. (In a larger organisation with separate
> teams for SVN administration, programming, QS, and rollout, this is
> bound to become even more painful.)
This cannot be done with hooks. There is no pre-export hook.
> So how about *client-side* hook scripts? Have a parameter --hook-
> dir for the SVN client. With a hook for checking whether a given
> file should be exported at all, and a hook for munging the contents
> of a file (possibly even before the file is written to disk: piping
> the file contents to stdin of the hook script would suffice).
Client-side hooks are not available, and probably never will be.
There are about a zillion threads in the mailing list archives if
you'd like to review them. Basically, it's a security issue to allow
code that someone committed to the repository to be run on the
client. Not to mention that it's very difficult to write a script
that works properly on all possible client environments, given the
poor scripting support built into Windows for example. And what
you're asking for -- the ability to tell the repository what to send
and not to send -- goes even further.
Hey, actually, if that's all you want, couldn't you just ask the
repository for a list of files first, and then only request the ones
you actually want? You may have to dig into the APIs, like the Perl
API for example, to do this optimally.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: attempt to write a readonly database - indexes.sqlite
Posted by Andy Levy <an...@gmail.com>.
Please be aware that 1.5 has *not* been released yet, and therefore
you are running a development version which is most likely buggy; the
issue you're encountering may have already been resolved in a later
version.
You'll probably need the help of an SVN developer (unreleased software
isn't officially supported AFAIK), and be sure to report the revision
your version was built from; this should be reported by svn --version.
On Nov 21, 2007 10:31 AM, Christian Ruffer <ru...@concarnet.de> wrote:
> I use 1.5 - It is part of openSuSE 10.3.1-factory.
>
> concarnet - Die Internetlösung für Fleischer.
> Fabian Krumbholz & Christian Ruffer GbR
>
> Bayerstraße 89, D-80335 München
> Fon: (089) 52031048
> Fax: (089) 52031053
>
> ruffer@concarnet.de
> http://www.concarnet.de/
>
> Andy Levy schrieb:
>
> > On Nov 21, 2007 5:59 AM, Christian Ruffer <ru...@concarnet.de> wrote:
> >> Hello,
> >>
> >> I got the error: "attempt to write a readonly database" after a commit.
> >> I figured out, that the indexes.sqlite file on the server has only write
> >> permissions for my college. (rw-r--r-- user1)
> >> When I changed the permissions to rw-rw-rw- I was able to commit.
> >>
> >> When deleting the indexes.sqlite it appears again when my college makes
> >> an commit. It has again only write-permissions for him.
> >>
> >> What das the indexes.sqlite file do and why does it only appear when my
> >> college is commiting?
> >> Why are the permissions of indexes.sqlite only set to write for him?
> >
> > What version are you running? IIRC, SQLite doesn't make an appearance
> > in Subversion until 1.5, which isn't even a release candidate yet.
> >
>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: attempt to write a readonly database - indexes.sqlite
Posted by Christian Ruffer <ru...@concarnet.de>.
I use 1.5 - It is part of openSuSE 10.3.1-factory.
concarnet - Die Internetlösung für Fleischer.
Fabian Krumbholz & Christian Ruffer GbR
Bayerstraße 89, D-80335 München
Fon: (089) 52031048
Fax: (089) 52031053
ruffer@concarnet.de
http://www.concarnet.de/
Andy Levy schrieb:
> On Nov 21, 2007 5:59 AM, Christian Ruffer <ru...@concarnet.de> wrote:
>> Hello,
>>
>> I got the error: "attempt to write a readonly database" after a commit.
>> I figured out, that the indexes.sqlite file on the server has only write
>> permissions for my college. (rw-r--r-- user1)
>> When I changed the permissions to rw-rw-rw- I was able to commit.
>>
>> When deleting the indexes.sqlite it appears again when my college makes
>> an commit. It has again only write-permissions for him.
>>
>> What das the indexes.sqlite file do and why does it only appear when my
>> college is commiting?
>> Why are the permissions of indexes.sqlite only set to write for him?
>
> What version are you running? IIRC, SQLite doesn't make an appearance
> in Subversion until 1.5, which isn't even a release candidate yet.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: attempt to write a readonly database - indexes.sqlite
Posted by Andy Levy <an...@gmail.com>.
On Nov 21, 2007 5:59 AM, Christian Ruffer <ru...@concarnet.de> wrote:
> Hello,
>
> I got the error: "attempt to write a readonly database" after a commit.
> I figured out, that the indexes.sqlite file on the server has only write
> permissions for my college. (rw-r--r-- user1)
> When I changed the permissions to rw-rw-rw- I was able to commit.
>
> When deleting the indexes.sqlite it appears again when my college makes
> an commit. It has again only write-permissions for him.
>
> What das the indexes.sqlite file do and why does it only appear when my
> college is commiting?
> Why are the permissions of indexes.sqlite only set to write for him?
What version are you running? IIRC, SQLite doesn't make an appearance
in Subversion until 1.5, which isn't even a release candidate yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
attempt to write a readonly database - indexes.sqlite
Posted by Christian Ruffer <ru...@concarnet.de>.
Hello,
I got the error: "attempt to write a readonly database" after a commit.
I figured out, that the indexes.sqlite file on the server has only write
permissions for my college. (rw-r--r-- user1)
When I changed the permissions to rw-rw-rw- I was able to commit.
When deleting the indexes.sqlite it appears again when my college makes
an commit. It has again only write-permissions for him.
What das the indexes.sqlite file do and why does it only appear when my
college is commiting?
Why are the permissions of indexes.sqlite only set to write for him?
best regards,
christian ruffer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Exporting with externals doesn't work
Posted by Joachim Durchholz <jo...@durchholz.org>.
Ryan Schmidt schrieb:
> I believe the bug occurs any time you try to export from a working
> copy (regardless of what protocol you used to check the working copy
> out with), and I believe the bug does not occur if you try to export
> from a repository URL (again, regardless of the protocol). But I have
> not tested every protocol.
OK, I'll have to try it out.
Thinking about alternatives:
Since the script is doing a rollout, which means walking the directory
and munging files anyway: is an exported tree equivalent to a
checked-out repository with the .svn directories removed?
In that case, I could simply copy the repository tree and skip the
unwanted files (i.e. .svns and some other stuff that I'm currently
stripping after the export). This would also speed up the process
because the repository contains some large binary files that aren't
going into production anyway (test data and such).
Another alternative: wait for 1.5.
Should I hold my breath?
Regards,
Jo
P.S.: Re CCing and reply-to headers: Thunderbird isn't smart enough to
properly react to mailing-list headers. I've been considering dropping
TB for a while now, it's just that I haven't come across a satisfactory
alternative yet...)
P.P.S.: I think that "export from the respository and have some file
munging" scenario is quite common. That's not really attractive though:
e.g. when rolling out for the customer, you don't want to first export
several megabytes of versioned test data just to delete them afterwards;
you'd want to filter them even before they get transmitted from the
repository to the rollout directory.
My knee-jerk reaction was "use a hook script then"; however, since every
hook script must serve all needs, this means that you have to coordinate
closely that the export will do something differently depending on
whether the checkout/export is for programming, for testing, or for
rollout. (In a larger organisation with separate teams for SVN
administration, programming, QS, and rollout, this is bound to become
even more painful.)
So how about *client-side* hook scripts? Have a parameter --hook-dir for
the SVN client. With a hook for checking whether a given file should be
exported at all, and a hook for munging the contents of a file (possibly
even before the file is written to disk: piping the file contents to
stdin of the hook script would suffice).
Just tossing around an idea and looking whether it's useful to anybody ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Exporting with externals doesn't work
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 20, 2007, at 16:52, Joachim Durchholz wrote:
> Ryan Schmidt schrieb:
>> On Nov 20, 2007, at 07:19, Joachim Durchholz wrote:
>>> I'm exporting from a directory with several svn:externals
>>> definitions.
>>>
>>> If I do this with TortoiseSVN, I get the external subdirectories.
>>>
>>> If I do this with the Win32 packages built against Apache 2.2
>>> from svn.tigris.org (http://tinyurl.com/yqjfbm), I do not get the
>>> external subdirectories.
>> [snip]
>>> Is this a bug?
>> It's a bug which looks like it will be fixed in Subversion 1.5:
>> http://subversion.tigris.org/issues/show_bug.cgi?id=2429
>
> Ah. I must have done something wrong when checking for that bug on
> tigris.org.
By default it only searches for open bugs; the bug is closed because
it has already been fixed in trunk.
>> The bug notes include a workaround you can use until then, at
>> least on computers that have the "rsync" command (i.e. anything
>> Unix-y).
>
> Oh, rsync is available for Windows, too.
>
>> You can also export from a repository URL instead of from a
>> working copy; that should work too. Maybe that's what TortoiseSVN
>> is doing to get it to work; I don't know.
>
> OK, an svn+ssh URL would work. I'd have to redo a whole lot of
> scripts that assume they can work off the checked-out repository
> though, so I'd like to avoid that if possible.
>
> Does anybody know if the bug happens with file: URLs, too?
> (I can't easily test, I keep getting this kind of URL wrong for
> some reason that I haven't found the time to properly investigate
> yet.)
I believe the bug occurs any time you try to export from a working
copy (regardless of what protocol you used to check the working copy
out with), and I believe the bug does not occur if you try to export
from a repository URL (again, regardless of the protocol). But I have
not tested every protocol.
> P.S.: No need to CC messages to me, thanks.
I can't keep track of who wants copies and who doesn't. If you don't
want copies, you can change the Reply-To header of your outgoing
mails to be the list's address.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Exporting with externals doesn't work
Posted by Joachim Durchholz <jo...@durchholz.org>.
Ryan Schmidt schrieb:
> On Nov 20, 2007, at 07:19, Joachim Durchholz wrote:
>
>> I'm exporting from a directory with several svn:externals definitions.
>>
>> If I do this with TortoiseSVN, I get the external subdirectories.
>>
>> If I do this with the Win32 packages built against Apache 2.2 from
>> svn.tigris.org (http://tinyurl.com/yqjfbm), I do not get the external
>> subdirectories.
>
> [snip]
>
>> Is this a bug?
>
> It's a bug which looks like it will be fixed in Subversion 1.5:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=2429
Ah. I must have done something wrong when checking for that bug on
tigris.org.
> The bug notes include a workaround you can use until then, at least on
> computers that have the "rsync" command (i.e. anything Unix-y).
Oh, rsync is available for Windows, too.
> You can also export from a repository URL instead of from a working
> copy; that should work too. Maybe that's what TortoiseSVN is doing to
> get it to work; I don't know.
OK, an svn+ssh URL would work. I'd have to redo a whole lot of scripts
that assume they can work off the checked-out repository though, so I'd
like to avoid that if possible.
Does anybody know if the bug happens with file: URLs, too?
(I can't easily test, I keep getting this kind of URL wrong for some
reason that I haven't found the time to properly investigate yet.)
Regards,
Jo
P.S.: No need to CC messages to me, thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Exporting with externals doesn't work
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 20, 2007, at 07:19, Joachim Durchholz wrote:
> I'm exporting from a directory with several svn:externals definitions.
>
> If I do this with TortoiseSVN, I get the external subdirectories.
>
> If I do this with the Win32 packages built against Apache 2.2 from
> svn.tigris.org (http://tinyurl.com/yqjfbm), I do not get the
> external subdirectories.
[snip]
> Is this a bug?
It's a bug which looks like it will be fixed in Subversion 1.5:
http://subversion.tigris.org/issues/show_bug.cgi?id=2429
The bug notes include a workaround you can use until then, at least
on computers that have the "rsync" command (i.e. anything Unix-y).
You can also export from a repository URL instead of from a working
copy; that should work too. Maybe that's what TortoiseSVN is doing to
get it to work; I don't know.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org