You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Markus Wolff <wo...@21st.de> on 2004/04/09 15:01:07 UTC
Unversioned files in working copies
Hi there,
I've recently started using Subversion in favor of CVS as it's easier
to administrate, however, I still got some problems and I hope someone
here can point me into the right direction.
The most recent and annoying problem is this:
I have a modular application written in PHP which is divided into...
- a main repository, where the bulk of common scripts and class files
is being versioned
- several small repositories with only the plugins for specific
clients
(Note: I *have* to split the repositories for copyright reasons, as
the main repository is open source and thus publically available,
while the specialized plugins are not.)
When testing the app, I need to combine those files. As I most often
make changes in the main repository, I make a working copy of that one
and copy in all the client-specific files by hand to complete my
testing environment.
Now, whenever I change something from the main repository, I can just
hit "commit" in RapidSVN, and I only need to copy changes over to the
specialized repository when I make changes to one of the files that
are unversioned in this copy.
When I do an update on my working copy, however, I can't just hit
update on the top-level directory anymore to have the whole repository
updated - Subversion always complains about not being able to update
unversioned files and doesn't update anything at all. So I have to
update every directory by hand :-(
Examples for Subversion's complaints:
"Execute: Update
Error while performing action: Working copy '...path...' not locked"
"Execute: Update
Error while performing action: REPORT request failed on
'...path.../!svn/vcc/default'
File not found: transaction '77', path '...path...'"
Is there any way how I can just recursively update a whole working
copy without Subversion complaining about unversioned files?
Thanks a lot for any hints!
CU
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: REPORT Request failed
Posted by Karl Robillard <ka...@vision-scape.com>.
This problem seems to be related to whats going on in the "Unversioned files
in working copies" thread.
One of the things that seems to trigger the problem is when Windows users add
a file that already exists but with a different case. Since the server is
running on Linux this is fine, but when another Windows user tries to update
he will get an error saying the file already exits. If I delete the
duplicate file from SVN and the Windows user reverts, the file will be
deleted but there is still a .tmp file for it in the .svn directory which
causes problems when trying to update.
I have seen this at least once: A successfull update was done on the directory
which is given in the 'File not found: transaction ...' error, but an update
from higher in the tree immediately thereafter gives the same error.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files in working copies
Posted by Vincent Lefevre <vi...@vinc17.org>.
> svn up
>
> (will also update '.') or
>
> svn up `svn list`
>
> but this will also update files starting with '.'.
Hmm... forget that. It will also retrieve new files/directories.
Shouldn't svn have an option to ignore uncontrolled files?
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
Championnat International des Jeux Mathématiques et Logiques, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files in working copies
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2004-04-09 17:48:21 +0200, Markus Wolff wrote:
> The directory "myplug" is not under version control in the main
> repository anymore, but it has been in the past.
>
> Could this be the problem? If so, is there any way to correct this?
svn up
(will also update '.') or
svn up `svn list`
but this will also update files starting with '.'.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
Championnat International des Jeux Mathématiques et Logiques, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files in working copies
Posted by Markus Wolff <wo...@21st.de>.
Markus Wolff wrote:
> Currently, I can't reproduce the transaction error mentioned earlier
> though, as I've tried to update only the directory that SVN complained
> about, which was successful, and now I don't get the error anymore even
> when doing a batch update on the parent directory.
Not true anymore, now I can reproduce that error with another directory:
<TRANSCRIPT>
mwolff@BigBlueThingy plugins]$ ls
adresse/ beziehungen/ myplug/ kontakthistorie/
medien/ pressemitteilungen/ uebersicht/
bankverbindung/ dynamic_category/ kommunikation/ languages/
personen/ typen/
[mwolff@BigBlueThingy plugins]$ svn update *
At revision 156.
At revision 156.
At revision 156.
At revision 156.
svn: REPORT request failed on '/svn/21st/deepcode9/!svn/vcc/default'
svn:
File not found: transaction '7c', path
'/module/crm/person/plugins/myplug/scripts'
</TRANSCRIPT>
The directory "myplug" is not under version control in the main
repository anymore, but it has been in the past.
Could this be the problem? If so, is there any way to correct this?
CU
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files in working copies
Posted by Markus Wolff <wo...@21st.de>.
Ben Collins-Sussman wrote:
>>The directory "schnelleintrag", in this case, has been in the main
>>repository before, but has then been deleted from there and moven out
>>to a spezialized repository, so it's now regarded unversioned by
>>Subversion when appearing in this working copy.
>
> Are you *sure* about this? What does "deleted and moved out" mean? Did
> you just use Unix 'rm' to delete the thing, rather than actually 'svn
> rm' the directory and commit?
It's in fact not in the repository. I used RapidSVN to remove it and
committed the action.
> Because to me, it looks like the directory "schnelleintrag" is still in
> the repository, and therefore 'svn up' is trying to re-add it. And an
> unversioned directory by the same name is sitting in the way.
>
> Run 'svn ls' on the parent directory's URL (whatever the URL to
> module/crm is). Do you see "schnelleintrag" in the repository still?
> What does 'svn status' say about the module/crm/ directory?
Here's what it says:
[mwolff@BigBlueThingy crm]$ svn ls
common/
pathfinder.php
person/
security.php
stammdaten/
suche/
[mwolff@BigBlueThingy crm]$ svn status
? schnelleintrag
! .
! person
! person/plugins
M person/plugins/adresse/scripts/details.php
! person/plugins/myplug
? person/plugins/myplug/scripts/index_orig.php
! person/plugins/myplug/scripts
M person/plugins/myplug/scripts/index.php
? person/plugins/uebersicht/scripts/customized_data.php
M stammdaten/index.php
CU
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files in working copies
Posted by Markus Wolff <wo...@21st.de>.
Jonathan Abbey wrote:
> | Another possibility is that somehow the directory is missing in the
> | repository, but somehow your working copy of the parent directory still
> | has "schnelleintrag" listed in its .svn/entries file. So 'svn up' is
> | trying to traverse into the child to send a "report" to the server. But
> | the child isn't under version control anymore.
>
> I bet that's precisely what's going on. He used RapidSVN to remove
> the schnelleintrag directory, as he said, but since he didn't do the
> removal in the context of his working directory, it would make sense
> that his entries file has a lingering reference to schnelleintrag.
Hey guys,
I just wanted to let you know that your assumptions were correct -
there must have been something broken in my working copy.
Once I got rid of that copy, made a new fresh checkout of the whole
repository and put the unversioned file back in the directory tree,
everything worked like a charm - I guess this is what I should have
tried in the first place, would have saved a lot of time.
Anyway, thanks guys - at least now I know that even the support on
this list is really good, so I'm even more convinced now than I was
before that switching from CVS to SVN was a Good Thing (tm) ;-)
CU
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files in working copies
Posted by Jonathan Abbey <jo...@arlut.utexas.edu>.
On Fri, Apr 09, 2004 at 11:17:10AM -0500, Ben Collins-Sussman wrote:
| On Fri, 2004-04-09 at 11:03, Ben Collins-Sussman wrote:
|
| > > The directory "schnelleintrag", in this case, has been in the main
| > > repository before, but has then been deleted from there and moven out
| > > to a spezialized repository, so it's now regarded unversioned by
| > > Subversion when appearing in this working copy.
| >
| > Are you *sure* about this? What does "deleted and moved out" mean? Did
| > you just use Unix 'rm' to delete the thing, rather than actually 'svn
| > rm' the directory and commit?
| >
| > Because to me, it looks like the directory "schnelleintrag" is still in
| > the repository, and therefore 'svn up' is trying to re-add it. And an
| > unversioned directory by the same name is sitting in the way.
|
| Another possibility is that somehow the directory is missing in the
| repository, but somehow your working copy of the parent directory still
| has "schnelleintrag" listed in its .svn/entries file. So 'svn up' is
| trying to traverse into the child to send a "report" to the server. But
| the child isn't under version control anymore.
I bet that's precisely what's going on. He used RapidSVN to remove
the schnelleintrag directory, as he said, but since he didn't do the
removal in the context of his working directory, it would make sense
that his entries file has a lingering reference to schnelleintrag.
| The best way to de-confuse things is to show us a step-by-step
| transcript of the procedure you use to bootstrap your work environment.
| Show us how you do a checkout of your main repository, then show us how
| you place unversioned stuff into it, and then show us how update is
| failing. We need a long transcript. My suspicion is that there's a
| subtle driver-error going on here, but I won't be able to point it out
| until I see a transcript that starts from the very beginning.
--
-------------------------------------------------------------------------------
Jonathan Abbey jonabbey@arlut.utexas.edu
Applied Research Laboratories The University of Texas at Austin
GPG Key: 71767586 at keyserver pgp.mit.edu, http://www.ganymeta.org/workkey.gpg
Re: Unversioned files in working copies
Posted by Ben Collins-Sussman <su...@collab.net>.
On Fri, 2004-04-09 at 11:03, Ben Collins-Sussman wrote:
> > The directory "schnelleintrag", in this case, has been in the main
> > repository before, but has then been deleted from there and moven out
> > to a spezialized repository, so it's now regarded unversioned by
> > Subversion when appearing in this working copy.
>
> Are you *sure* about this? What does "deleted and moved out" mean? Did
> you just use Unix 'rm' to delete the thing, rather than actually 'svn
> rm' the directory and commit?
>
> Because to me, it looks like the directory "schnelleintrag" is still in
> the repository, and therefore 'svn up' is trying to re-add it. And an
> unversioned directory by the same name is sitting in the way.
Another possibility is that somehow the directory is missing in the
repository, but somehow your working copy of the parent directory still
has "schnelleintrag" listed in its .svn/entries file. So 'svn up' is
trying to traverse into the child to send a "report" to the server. But
the child isn't under version control anymore.
The best way to de-confuse things is to show us a step-by-step
transcript of the procedure you use to bootstrap your work environment.
Show us how you do a checkout of your main repository, then show us how
you place unversioned stuff into it, and then show us how update is
failing. We need a long transcript. My suspicion is that there's a
subtle driver-error going on here, but I won't be able to point it out
until I see a transcript that starts from the very beginning.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files in working copies
Posted by Ben Collins-Sussman <su...@collab.net>.
On Fri, 2004-04-09 at 10:43, Markus Wolff wrote:
> It's not the point that I want it to overwrite unversioned files, it
> just shouldn't complain when there are unversioned files in the same
> directory as the working copy. The files wouldn't be overwritten by
> any file under version control because they don't exist in the repository.
'svn up' doesn't care when your working copy has unversioned files. It
only cares when an unversioned file is obstructing the update (i.e. in
the way of versioned things it's trying to add or change.)
Which means there is something deeply messed up about your working
copy. I'm trying to figure out what you did...
> Okay, here's a transcript, using the commandline this time:
>
> [mwolff@BigBlueThingy lastresort]$ svn update module
> svn: Working copy 'module/crm/schnelleintrag' not locked
>
> The directory "schnelleintrag", in this case, has been in the main
> repository before, but has then been deleted from there and moven out
> to a spezialized repository, so it's now regarded unversioned by
> Subversion when appearing in this working copy.
Are you *sure* about this? What does "deleted and moved out" mean? Did
you just use Unix 'rm' to delete the thing, rather than actually 'svn
rm' the directory and commit?
Because to me, it looks like the directory "schnelleintrag" is still in
the repository, and therefore 'svn up' is trying to re-add it. And an
unversioned directory by the same name is sitting in the way.
Run 'svn ls' on the parent directory's URL (whatever the URL to
module/crm is). Do you see "schnelleintrag" in the repository still?
What does 'svn status' say about the module/crm/ directory?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files in working copies
Posted by Markus Wolff <wo...@21st.de>.
Ben Collins-Sussman wrote:
>> Examples for Subversion's complaints:
>> "Execute: Update
>> Error while performing action: Working copy '...path...' not locked"
>> "Execute: Update
>> Error while performing action: REPORT request failed on
>> '...path.../!svn/vcc/default'
>> File not found: transaction '77', path '...path...'"
>
> Can you please show us a specific example? Like a transcript?
Hi Ben,
thanks for that ultra-quick answer :-)
Okay, here's a transcript, using the commandline this time:
[mwolff@BigBlueThingy lastresort]$ svn update module
svn: Working copy 'module/crm/schnelleintrag' not locked
The directory "schnelleintrag", in this case, has been in the main
repository before, but has then been deleted from there and moven out
to a spezialized repository, so it's now regarded unversioned by
Subversion when appearing in this working copy.
Currently, I can't reproduce the transaction error mentioned earlier
though, as I've tried to update only the directory that SVN complained
about, which was successful, and now I don't get the error anymore
even when doing a batch update on the parent directory.
>> Is there any way how I can just recursively update a whole working
>> copy without Subversion complaining about unversioned files?
>
> No. 'svn up' absolutely will not overwrite unversioned files. But it's
> not entirely clear that's the problem here. Those errors above look
> strange, like you're doing something really bad to your working copy.
It's not the point that I want it to overwrite unversioned files, it
just shouldn't complain when there are unversioned files in the same
directory as the working copy. The files wouldn't be overwritten by
any file under version control because they don't exist in the repository.
CU
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files in working copies
Posted by Ben Collins-Sussman <su...@collab.net>.
Markus Wolff wrote:
> Examples for Subversion's complaints:
> "Execute: Update
> Error while performing action: Working copy '...path...' not locked"
> "Execute: Update
> Error while performing action: REPORT request failed on
> '...path.../!svn/vcc/default'
> File not found: transaction '77', path '...path...'"
>
Can you please show us a specific example? Like a transcript?
> Is there any way how I can just recursively update a whole working copy
> without Subversion complaining about unversioned files?
No. 'svn up' absolutely will not overwrite unversioned files. But it's
not entirely clear that's the problem here. Those errors above look
strange, like you're doing something really bad to your working copy.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org