You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Steve Strobel <st...@link-comm.com> on 2008/10/07 16:24:39 UTC
svn cp treats filename as directory name
I am having trouble with the following command (under Ubuntu 8.04
using Subversion command-line client, version 1.4.6):
svn cp -r232 svn://192.168.25.29/trunk/linux-2.6.x/sound/blackfin/Makefile \
svn://192.168.25.29/trunk/linux-2.6.x/sound/blackfin/Makefile \
-m "Copying from rev 232 to maintain history of the files we changed."
I am trying to copy an older revision of that Makefile to the head.
A similar command works fine on some other files, but in this case
(and a few others) I get the error message:
svn: Failure opening '/trunk/linux-2.6.x/sound/blackfin/Makefile/Makefile'
svn: '/trunk/linux-2.6.x/sound/blackfin/Makefile' is not a directory in filesystem 'C:/Shared/SVN_Repo_uClinux/db'
Note that the error message indicates that it is looking
for .../Makefile/Makefile, which is not what the command says.
Also note that the filesystem it refers to, 'C:/Shared/SVN_Repo_uClinux/db'
is on a different computer that is running svnserve under Windows Vista (and
has worked fine for weeks). That path means nothing on my computer; I
always access the repository using svn://...
Running a verbose log and snipping the details about the other files:
svn log -v svn://192.168.25.29/trunk/linux-2.6.x/sound/blackfin/Makefile
------------------------------------------------------------------------
r300 | (no author) | 2008-10-06 16:30:35 -0600 (Mon, 06 Oct 2008) | 3 lines
Changed paths:
A /trunk (from /branches/vendor:299)
Copying the vendor branch with uClinux-dist-2008R1.5-RC3.tar.bz2.
------------------------------------------------------------------------
r234 | (no author) | 2008-09-04 15:12:03 -0600 (Thu, 04 Sep 2008) | 2 lines
Changed paths:
[snip]
M /branches/vendor/linux-2.6.x/sound/blackfin/Makefile
[snip]
[snip]
------------------------------------------------------------------------
r233 | Matt | 2008-09-04 10:56:29 -0600 (Thu, 04 Sep 2008) | 1 line
Changed paths:
A /branches/vendor (from /trunk:2)
Copied remotely
------------------------------------------------------------------------
r2 | (no author) | 2007-07-17 10:35:25 -0600 (Tue, 17 Jul 2007) | 2 lines
Changed paths:
[snip]
A /trunk/linux-2.6.x/sound/blackfin/Makefile
[snip]
As originally extracted from uClinux-dist-2007R1-RC3.tar.bz2.
------------------------------------------------------------------------
It appears to me that the Makefile was added to trunk in rev 2, then added again
(because of a copy) in rev 300. I think the changes in branches/vendor should be irrelevant.
Using svn ls to check whether the Makefile can be found in various revisions:
svn ls -r232 svn://192.168.25.29/trunk/linux-2.6.x/sound/blackfin/Makefile
svn: Unable to find repository location for 'svn://192.168.25.29/trunk/linux-2.6.x/sound/blackfin/Makefile' in revision 232
It doesn't seem to think that the Makefile existed in revision 232. That might explain why it
would try to treat .../blackfin/Makefile as a directory, but I still can't understand why it would
look for .../blackfin/Makefile/Makefile - that seems like a bug to me. The command only says
"Makefile" once; it might be a filename or a directory, but it shouldn't be both.
Trying svn ls on various revisions and noting the versions in which it can be found:
1 - no
2 - yes
3 - no
232 - no
233 - yes
234 - yes
299 - yes
300 - yes
301 - yes
head - yes
I don't understand why it disappeared between rev 2 and rev 233. I would think that
after being added in rev 2, that it would continue to exist on that path unless later
deleted. I also don't understand why it came back in rev 233; that should have just
added it in the branches/vendor directory and had no effect on trunk.
I don't see any reason it would exist in the trunk (per svn ls -r) in rev 2, then
disappear until rev 233. Am I missing something? Is there a problem with Subversion
or my repository? Thanks for any help.
Steve
---
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)
WWW: http://www.link-comm.com
MailTo:steve.strobel@link-comm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn cp treats filename as directory name
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Oct 7, 2008, at 16:45, Steve Strobel wrote:
>> svn cp svn://192.168.25.29/trunk/linux-2.6.x/sound/blackfin/
>> Makefile@232 svn://192.168.25.29/trunk/linux-2.6.x/sound/blackfin/
>> Makefile -m "Copying from rev 232 to maintain history of the files
>> we changed."
>> svn: Failure opening '/trunk/linux-2.6.x/sound/blackfin/Makefile/
>> Makefile'
>> svn: '/trunk/linux-2.6.x/sound/blackfin/Makefile' is not a
>> directory in filesystem 'C:/Shared/SVN_Repo_uClinux/db'
>>
>> What is the correct syntax to copy (with history) that Makefile as
>> it existed in the trunk in rev 232 to the head?
>
> I finally figured out how to do what I want to do, but I still
> think that the error messages
> Subversion prints are less than helpful, and in the case where it
> repeats "...Makefile/Makefile",
> just plain wrong (I could see it interpreting my command to mean
> either a file
> called "Makefile" or a directory called "Makefile", but there is no
> way that command
> could mean ".../Makefile/Makefile").
>
> My problem was that linux-2.6.x/sound/blackfin/Makefile already
> existed in the trunk.
> Apparently "svn copy" doesn't overwrite, so you have to "svn
> delete" then "svn update"
> the file before doing the "svn copy". Otherwise you get a message
> about the file
> not being a directory. How intuitive :( I would like to suggest
> a different error message,
> maybe something like
>
> svn: Failure copying '/trunk/linux-2.6.x/sound/blackfin/Makefile'.
> File already exists.
Correct, Subversion does not overwrite files when you use "svn cp".
You must remove the existing item first with "svn rm" if you want to
overwrite it.
Subversion noticed "Makefile" existed in the destination, and seems
to have continued as if it were a directory, thus trying to copy your
source "Makefile" into the destination directory "Makefile" (with the
resulting file's path being "Makefile/Makefile"). But it failed
because the destination directory "Makefile" was not a directory.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn cp treats filename as directory name
Posted by Steve Strobel <st...@link-comm.com>.
>svn cp svn://192.168.25.29/trunk/linux-2.6.x/sound/blackfin/Makefile@232 svn://192.168.25.29/trunk/linux-2.6.x/sound/blackfin/Makefile -m "Copying from rev 232 to maintain history of the files we changed."
>svn: Failure opening '/trunk/linux-2.6.x/sound/blackfin/Makefile/Makefile'
>svn: '/trunk/linux-2.6.x/sound/blackfin/Makefile' is not a directory in filesystem 'C:/Shared/SVN_Repo_uClinux/db'
>
>What is the correct syntax to copy (with history) that Makefile as it existed in the trunk in rev 232 to the head?
I finally figured out how to do what I want to do, but I still think that the error messages
Subversion prints are less than helpful, and in the case where it repeats "...Makefile/Makefile",
just plain wrong (I could see it interpreting my command to mean either a file
called "Makefile" or a directory called "Makefile", but there is no way that command
could mean ".../Makefile/Makefile").
My problem was that linux-2.6.x/sound/blackfin/Makefile already existed in the trunk.
Apparently "svn copy" doesn't overwrite, so you have to "svn delete" then "svn update"
the file before doing the "svn copy". Otherwise you get a message about the file
not being a directory. How intuitive :( I would like to suggest a different error message,
maybe something like
svn: Failure copying '/trunk/linux-2.6.x/sound/blackfin/Makefile'. File already exists.
Steve
---
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)
WWW: http://www.link-comm.com
MailTo:steve.strobel@link-comm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Creating and using child repositories of repositories which contain externals.
Posted by "Looking through a Glass Onion." <ze...@yahoo.com>.
Hi Rush,
Thanks for the reply, great question, and the answer would be a
resounding "Yes!" -- but -- we've inherited our build environment from a
world of Windows code, and part of the complexity of our "views" is that
we've had to write Makefiles that uses $OS[TYPE] to spawn the correct
build tools for either environment. We're using Fedora, and I'm using OS
X to do my research, which all-in-all is a joy. That said, we're
considering cygwin, so maybe that winds up being easier than figuring this
out in svn -- I'll definitely consider this path (it may end up being a
no-op since building the code in one 'View' would mean getting it build in
another, and I'd have to be sure that wouldn't effect any of our release
mechanisms -- we definitely haven't inherited an elegant environment --
then there's the performance 'hit' to consider running the cygwin
emulation layer, etc).
I think I've even seen an svn command where the checkout will auto-create
these links, and where it also stated that it wasn't supported on Windows
and provided a link to svn:externals documentation, so maybe the
'externals' thing was all originally Windows "inspired?" Someone with
some history here will have to comment on that.
As for the rest of you comment, another "yes" -- if someone makes
changes to the same file in two places, even if that second place is an
external of the first, or if the first place is an external of the second,
svn rightly refuses to process them. Potentially more confusingly, if
someone makes changes in one place, `svn stat` (etc) doesn't show them the
connected file as having changed. Plus the fact that externals point to
one place is playing into my considerations for what happens if/when we
branch; externals in the branch will point to the trunk by default, so
they'll have to be changed in the branch as something to remember to do.
Linking would make both of these issues disappear!
No -- inheriting Windows hasn't made our life easy! 8^)
Cheers,
Steve
"A dude with a pencil is worse than a cat with a machine gun"
-- Ellas Otha Bates (Bo Diddley) 1928 - 2008
--- On Tue, 10/7/08, Rush Manbert <ru...@manbert.com> wrote:
> From: Rush Manbert <ru...@manbert.com>
> Subject: Re: Creating and using child repositories of repositories which contain externals.
> To: zentechno@yahoo.com
> Cc: users@subversion.tigris.org
> Date: Tuesday, October 7, 2008, 3:14 PM
> Hi Steve,
>
> Since you seem to be on some flavor of Unix, wouldn't
> it be a lot
> easier and cleaner to just set up the views as links to the
> checked
> out directories? Then all of your views that use componentX
> would be
> linked to the checked out copy of trunk/componentX, and any
> changes
> made in any view, or in the real working copy, would be
> reflected in
> the checked out trunk/componentX. You could test all of
> your views
> before you check in, and it shouldn't be too hard to
> write a script
> that knows how to construct the views directory trees.
>
> I would expect that, given the repository structure you
> showed in your
> original post, your developers could run into trouble if
> they check
> out the trunk, then modify some file, say foo.c in
> checkoutTop/
> componentX, and then also modify it in
> checkoutTop/views/A/componentX,
> then try to do a commit from checkoutTop. But I'm
> anything but a SVN
> expert, so you can't really believe anything I say. :-)
>
> - Rush
>
>
>
> ---------------------------------------------------------------------
> 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: Creating and using child repositories of repositories which contain externals.
Posted by Rush Manbert <ru...@manbert.com>.
Hi Steve,
Since you seem to be on some flavor of Unix, wouldn't it be a lot
easier and cleaner to just set up the views as links to the checked
out directories? Then all of your views that use componentX would be
linked to the checked out copy of trunk/componentX, and any changes
made in any view, or in the real working copy, would be reflected in
the checked out trunk/componentX. You could test all of your views
before you check in, and it shouldn't be too hard to write a script
that knows how to construct the views directory trees.
I would expect that, given the repository structure you showed in your
original post, your developers could run into trouble if they check
out the trunk, then modify some file, say foo.c in checkoutTop/
componentX, and then also modify it in checkoutTop/views/A/componentX,
then try to do a commit from checkoutTop. But I'm anything but a SVN
expert, so you can't really believe anything I say. :-)
- Rush
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Creating and using child repositories of repositories which contain externals.
Posted by "Looking through a Glass Onion." <ze...@yahoo.com>.
Hi, again, SVN folks!
First off, my apologies for not adhering to your request for limiting
email to 72-columns! I though my mailer auto-formatted my email, but it
apparently doesn't. I've included my original post in 72-column
friendly format, so if you ignored my email yesterday for this reason I
understand, though I'd like you to reconsider. 8^) I also have a few
things to add which I've considered/discovered since posting yesterday.
First a quick review relevant to what I'd like to add today:
MR -- Main Repository, shared by all engineers.
LR -- Local Repository, used by a single engineer.
LW -- Local Workspace, a checkout of MR, imported to LR.
WS -- a "generic" workspace, though strictly a checkout of LR.
There's also a directory layout included in my original email below
detailing the layout of the master and child repository, and externals
to which I refer (at least well enough to have this discussion).
The basic idea was to create a Local Repository, and populate it with
the checkout of the Main Repository, then use that as a synchronization
place to co/ci files that are externals so the deltas can be propagated
to all places within the Local Repository so the changes can be tested
prior to committing them to the Master Repository.
OK -- to add to this, I discovered the "--ignore-externals" option to
`svn export` -- though this helps with the final checkin to the
Main Repository, it doesn't help at the 'lower' layer where I need my
child repository to understand the externals so the deltas of a checked
in file can be replicated to its (origin and) externals -- the whole
point here as this facilitates 'test-before-commit' in all places that
externals is populated in the checkout. If the `svn import` option
accepted the same "--ignore-externals" option, I'd be golden here! Is
there an effort underway to add this, and/or to those who understand
this more deeply than I would this be a useful addition?
I'm writing a script to delete the on-disk copies of the externals in a
workspace (by that I mean the checkout of a repository). In this way
just the non-externals/locals can be imported into he child repository
(amounting to an `svn import --ignore-externals` ...), then another
script to re-create the externals in the child repository which simply
uses `svn propget -R svn:externals trunk` to build the list from the
Local Workspace, then re-creates them in the child repository.
I'd be happy to contribute this script and whatever I end up doing to
make this work -- provided I get it working -- if it seems like it could
useful to the effort here.
As a final note, I haven't overlooked the possibility that I'm missing
something very easy here! Please advise if you think I'm well off the
path!
Thanks for all your time.
Cheers,
Steve
--- On Mon, 10/6/08, Looking Through A Glass Onion <ze...@yahoo.com>
wrote:
> Begin forwarded message (cut-and-pasted from the web archive)
Date: Mon, 6 Oct 2008 16:32:10 -0700 (PDT)
From: Looking through a Glass Onion. <ze...@yahoo.com>
Content-Type: text/plain; charset=us-ascii
Subject: Creating and using child repositories of repositories which
contain externals.
Hi SVN people!
I've checked through the archives of this alias, and I've seen a few
queries regarding setting up local (a.k.a. 'child') repositories of
other repositories so version control can be done w/o network
connectivity, then committed 'en masse' to the main repository at
convenient times. The recommendation for this was to use SVK at
http://svk.bestpractical.com/ -- but they don't support externals
(at least not as of today's visit to
http://svk.bestpractical.com/view/SVKForSubversion
but I am investigating the 'proposal' and 'workaround'). I don't
think vendor branches work here either. In the mean time...
My company's svn repository uses svn:externals in probably a unique
way. We wanted to use a view-like mechanism, so we have a 'trunk' set
up that contains all our components, and also contains a 'views'
folder. The various views in the views folder contain sub-folders
which are externals to the components of that view. For example:
/trunk/
/trunk/componentX #some component
/trunk/componentY #some other component
/trunk/componentZ #yet another component
/trunk/componentT #one last component
/trunk/views/
/trunk/views/A/
/trunk/views/A/componentX #an external to /trunk/componentX
/trunk/views/A/componentY #an external to /trunk/componentY
/trunk/views/A/componentZ #an external to /trunk/componentZ
/trunk/views/B
/trunk/views/B/componentZ #an external to /trunk/componentZ
/trunk/views/B/componentT #an external to /trunk/componentT
In this way changes to the components code is automagically
propagated into the 'views' -- however (you may know where I'm going)
-- if I make a change to /trunk/views/A/componentZ it doesn't show in
/trunk/component/views/B/comonentZ until I commit the change. This is
somewhat anathema to a 'test-before-commit' methodology, as no matter
how much I test componentZ in the A view, there's no way to test-
before-commit in the B view unless I cold-copy the changes into
trunk/views/B, which creates other oddities for subversion when it
comes time to commit (or if not, because I limit the scope of my
commit, then during the update of those folders).
A solution I'd like to roll out in my own workspace(s) is to create
a child/local repository of code from our main repository. Then, by
checking out and committing via this child-repository I can synchronize
my changes in one place, test them in the effected views, then commit
these changes from my child/local repository back to the main
repository. This would work pretty seamlessly, actually, if it wasn't
for these externals (e.g. assuming for a moment no externals):
-- bring over the main repository code
`svn checkout http://svn/mainRepository/trunk ./MainTrunk`
-- create the child/local repository
`svnadmin create ./childRepository`
-- import the main code into the child repository
`svn import ./MainTrunk ./childRepository/trunk`
-- run svnserve
`svnserve -d -r ./childRepository
At this point I can co, update, ci any changes via the child
repository (e.g. on another machine, or to a different folder on the
same machine):
`svn co svn://<svnserveMachine>/trunk ./trunk`
When it comes time to check these back into the MainTrunk, I simply:
-- export childRepository code into the directory where the
mainRepository is located (using loopback to make the point):
`svn --export --force svn://127.0.0.1/trunk ./childRepository`
This 'materializes' the changes made to the child repository into
the code that was originally checked out of the main repository.
At this point, I simply ci this code:
`svn ci ./childRepository
and the code goes into the mainRepository.
That said, externals make this much more involved. During the
import phase, svn is smart enough to ignore the '.svn' folders, BUT
it's not smart enough to ignore the externals. This mean that in the
child repository, the externals are treated like separate files, and so
changes to them (e.g. via another checkout workspace) do NOT get
propagated at commit time. E.g. using the layout above, a change to
trunk/views/A/componentZ
does NOT get propogated to
trunk/views/B/componentZ
because the child repository sees them as different files.
I can see two ways to make this happen with externals (and to
finally get to my questions, please tell me if this seems like this/
either should work):
Option 1:
1) after the checkout of mainRepository, but before importing the
source files into the child repository, remove all the externals.
After the import, these folders can be easily replaced with another
checkout of the mainRepository.
2) after the import to the child repository, re-create the externals
in the childRepository by simply replicating the `svn propset
svn:externals ...` commands (e.g. create a shell script that uses
`svn propget svn:externals ...` of the main repository code to set the
externals of the child repository code).
In this way, a change to a checkout of the child repository will get
propagated to the externals folders with an update -- BUT what will
happen during the export of the childRepository into the source of the
checkout of the mainRepository?
-- If these changes are propagated, as I think it (of course)
will, then we have the same problem as using a single checkout and
copying the changes into all 'views' -- namely multiple changes to the
same file (as svn is designed to complain about).
-- If these changes are NOT propagated then there seems to be no
issues, and a subsequent checkin of this code into the mainRepository
should go correctly.
Option 2 (again, to the meat of a meaninful question): Is there
some way to get svn to ignore these externals during the import as it
does the '.svn' folders and even better, to also ignore these during
the export, too!)? If so, this seems like a much better solution as
it's all internal to svn, and requires no special handling time or
risks to folders and code.
Option 3 -- open to ideas!
Thanks for your time reading through all this. Looking forward to
some solution even if it involves shell scripts and/or changes to
repository hooks!
Cheers,
Steve
"All programs can be reduced to one line of code with a bug in it"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn cp treats filename as directory name
Posted by Steve Strobel <st...@link-comm.com>.
>I also noticed that when the Makefile "reappears" in revision 233
>that its contents match rev 2, as tested with
>svn diff -r2:233 svn://192.168.25.29/trunk/linux-2.6.x/sound/blackfin/Makefile
I thought I figured out how to make the svn cp work like I want it to. The key observation was that the history of /trunk does not include rev 232:
r303 | (no author) | 2008-10-07 08:24:09 -0600 (Tue, 07 Oct 2008) | 1 line
r302 | (no author) | 2008-10-06 16:31:42 -0600 (Mon, 06 Oct 2008) | 3 lines
r301 | (no author) | 2008-10-06 16:31:22 -0600 (Mon, 06 Oct 2008) | 4 lines
r300 | (no author) | 2008-10-06 16:30:35 -0600 (Mon, 06 Oct 2008) | 3 lines
Copying the vendor branch with uClinux-dist-2008R1.5-RC3.tar.bz2.
r282 | (no author) | 2008-10-02 12:23:05 -0600 (Thu, 02 Oct 2008) | 1 line
r234 | (no author) | 2008-09-04 15:12:03 -0600 (Thu, 04 Sep 2008) | 2 lines
r233 | Matt | 2008-09-04 10:56:29 -0600 (Thu, 04 Sep 2008) | 1 line
Copied remotely
r2 | (no author) | 2007-07-17 10:35:25 -0600 (Tue, 17 Jul 2007) | 2 lines
As originally extracted from uClinux-dist-2007R1-RC3.tar.bz2.
r1 | steve.strobel | 2007-07-13 10:41:50 -0600 (Fri, 13 Jul 2007) | 1 line
Before the remote copy in rev 233, I think I deleted everything in the trunk. That means
that the trunk head traces its history back to wherever that copy came from, which probably
wasn't earlier in the trunk. Looking into "peg revisions". Reading
<http://svnbook.red-bean.com/en/1.5/svn.advanced.pegrevs.html>http://svnbook.red-bean.com/en/1.5/svn.advanced.pegrevs.html. Trying:
svn ls -r232 svn://192.168.25.29/trunk/linux-2.6.x/sound/blackfin/Makefile # as before
svn: Unable to find repository location for 'svn://192.168.25.29/trunk/linux-2.6.x/sound/blackfin/Makefile' in revision 232
svn ls -r232 svn://192.168.25.29/trunk/linux-2.6.x/sound/blackfin/Makefile@232 # add peg revision
Makefile
svn ls svn://192.168.25.29/trunk/linux-2.6.x/sound/blackfin/Makefile@232 # remove -r
Makefile
That seems to work. Trying adding the peg revision with the svn cp command:
svn cp -r232 svn://192.168.25.29/trunk/linux-2.6.x/sound/blackfin/Makefile@232 svn://192.168.25.29/trunk/linux-2.6.x/sound/blackfin/Makefile -m "Copying from rev 232 to maintain history of the files we changed."
svn: Failure opening '/trunk/linux-2.6.x/sound/blackfin/Makefile/Makefile'
svn: '/trunk/linux-2.6.x/sound/blackfin/Makefile' is not a directory in filesystem 'C:/Shared/SVN_Repo_uClinux/db'
Not only did that not do what I hoped, it brought back the goofy error message with Makefile being used as both the file and directory name. I thought that upgrading the Subversion client had fixed that problem. Trying without -r:
svn cp svn://192.168.25.29/trunk/linux-2.6.x/sound/blackfin/Makefile@232 svn://192.168.25.29/trunk/linux-2.6.x/sound/blackfin/Makefile -m "Copying from rev 232 to maintain history of the files we changed."
svn: Failure opening '/trunk/linux-2.6.x/sound/blackfin/Makefile/Makefile'
svn: '/trunk/linux-2.6.x/sound/blackfin/Makefile' is not a directory in filesystem 'C:/Shared/SVN_Repo_uClinux/db'
What is the correct syntax to copy (with history) that Makefile as it existed in the trunk in rev 232 to the head? If it was just this one file, I could use svn log with the peg revision to figure out when it last changed (apparently rev 101 in this case, see below) and copy that version, but this part of a script and I need to do it for a number of files.
svn log svn://192.168.25.29/trunk/linux-2.6.x/sound/blackfin/Makefile@232
r106 | (no author) | 2007-10-09 10:07:20 -0600 (Tue, 09 Oct 2007) | 1 line
r2 | (no author) | 2007-07-17 10:35:25 -0600 (Tue, 17 Jul 2007) | 2 lines
Thanks for any suggestions,
Steve
---
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)
WWW: http://www.link-comm.com
MailTo:steve.strobel@link-comm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn cp treats filename as directory name
Posted by Steve Strobel <st...@link-comm.com>.
At 10:24 AM 10/7/2008, you wrote:
>I am having trouble with the following command (under Ubuntu 8.04
>using Subversion command-line client, version 1.4.6):
>[snip]
For what its worth, I updated to the
Subversion command-line client, version 1.5.1.
At least the error message it gives makes more sense:
svn cp -r232 svn://192.168.25.29/trunk/linux-2.6.x/sound/blackfin/Makefile \
svn://192.168.25.29/trunk/linux-2.6.x/sound/blackfin/Makefile \
-m "Copying from rev 232 to maintain history of the
files we changed."
svn: Unable to find repository location for
'svn://192.168.25.29/trunk/linux-2.6.x/sound/blackfin/Makefile' in revision 232
Everything else seems to work the same as version 1.4.6 (which still
doesn't seem right to me).
I also noticed that when the Makefile "reappears" in revision 233
that its contents match rev 2, as tested with
svn diff -r2:233 svn://192.168.25.29/trunk/linux-2.6.x/sound/blackfin/Makefile
Steve
---
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)
WWW: http://www.link-comm.com
MailTo:steve.strobel@link-comm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org