You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Dietrich Epp <di...@zdome.net> on 2003/11/15 19:34:43 UTC
Rolling Back Changes
I was shocked to find out that most of the files in a directory of my
project mysteriously disappeared in revision 53. So I tried this:
-----
$ svn copy file:///path/to/repository/subdir/English.lproj/ . -r 52
svn: Attempted to lock an already-locked dir
svn: working copy locked: .
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
details)
-----
I can't even figure out why the files disappeared in the first place,
but I do know that Subversion is entirely to blame. Here is some more
text from my terminal:
-----
Updated to revision 52.
$ ls
English.lproj/ Hammer.icns Level.icns MaraLevel2D.nib/
MaraLevel3D.nib/
$ svn rm MaraLevel2D.nib/
D MaraLevel2D.nib/objects.nib
D MaraLevel2D.nib/info.nib
D MaraLevel2D.nib/classes.nib
D MaraLevel2D.nib
$ svn ci -m 'Temporary.'
Replacing Resources
Committed revision 53.
-----
I'm using subversion 0.33.0. What's with the 'Replacing Resources'?
(Resources is the directory that the files disappeared from.)
On a side note, it's really ugly working with nib files in subversion.
When I want to change a nib file, I have to move .svn directories
around. It would be nice if subversion were smart enough not to put
.svn directories in nib files or other such places. This is really
important for Mac OS X developers, I'd rather have no move command than
have such poor handling of nib files.
On a side, side note... I couldn't find a link to subscribe to this
list on the project page. I guessed the email address for subscribing.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Rolling Back Changes
Posted by Ben Collins-Sussman <su...@collab.net>.
On Sat, 2003-11-15 at 13:34, Dietrich Epp wrote:
> I was shocked to find out that most of the files in a directory of my
> project mysteriously disappeared in revision 53.
Run 'svn log -r53 --verbose'. It will list the exact changes made in
r53. If you don't like the change, roll it back in your working copy,
and commit the "undo" as r54. Read chapter 4 in the book about how to
use 'svn merge' to do this.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Rolling Back Changes
Posted by kf...@collab.net.
Dietrich Epp <di...@zdome.net> writes:
> I apologize. I often post things with a skewed view when I can't get
> something to work the way I want it to, then I forget my earlier
> thinking. Maybe I should disable my mail program whenever something
> goes wrong... but then again.
Thanks :-). (I do understand the frustration, yes.)
> But I wasn't messing with interface builder when I did that. I was
> just deleting a directory which had been in my repository since the
> initial import, and a lot of other stuff got deleted too. Of course,
> I really have no proof for this.
Hmm. So at the moment, we don't know the cause for sure, and we don't
have a way to reproduce it... Ah well :-(. Keep an eye out for it
happening again; if it does, let us know. That's all we can do for
now, I guess.
> Loved your book on open source CVS development, BTW.
Thank you!
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Rolling Back Changes
Posted by Dietrich Epp <di...@zdome.net>.
On Nov 16, 2003, at 1:58 PM, kfogel@collab.net wrote:
> Dietrich Epp <di...@zdome.net> writes:
>> I don't consider it a problem in Interface Builder. It's just
>> something that Interface Builder does that Subversion doesn't
>> understand yet. Someday:
>>
>> svn propset svn:volatile yes *.nib
>>
>> And I didn't say it was a bug in subversion... but you saw what I
>> typed, and you saw what it did. For all I know it was a memory error.
>> All I know is that a directory with a handful of files suddenly had
>> only one after I committed.
>
> Dietrich, I'm going to have to call you on that one. Your first mail
> said:
>
> "I can't even figure out why the files disappeared in the first
> place, but I do know that Subversion is entirely to blame."
>
> Now later, after admitting that what probably happened is that
> Interface Builder *destroyed Subversion's metadata*, you still feel
> that Subversion is "entirely to blame"??
I apologize. I often post things with a skewed view when I can't get
something to work the way I want it to, then I forget my earlier
thinking. Maybe I should disable my mail program whenever something
goes wrong... but then again.
But I wasn't messing with interface builder when I did that. I was
just deleting a directory which had been in my repository since the
initial import, and a lot of other stuff got deleted too. Of course, I
really have no proof for this.
Loved your book on open source CVS development, BTW.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Final(?) problems building on Win32
Posted by Branko Čibej <br...@xbc.nu>.
Patrick Dean Rusk wrote:
> I have almost succeeded in compiling Subversion under Win32. The only remaining errors I
>get are listed below:
>
>
Upgrade to the newset Platform SDK.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Final(?) problems building on Win32
Posted by Patrick Dean Rusk <Pa...@comcast.net>.
I have almost succeeded in compiling Subversion under Win32. The only remaining errors I
get are listed below:
D:\Work\subversion-0.33.1>msdev subversion_msvc.dsw /MAKE "__ALL__ - Win32 Debug"
D:\Work\subversion-0.33.1\apr\include\apr_want.h(90): Could not find the file strings.h.
D:\Work\subversion-0.33.1\apr\include\apr_want.h(123): Could not find the file sys/uio.h.
D:\Work\subversion-0.33.1\apr\include\apr_want.h(141): Could not find the file
arpa/inet.h.
--------------------Configuration: neon - Win32 Debug--------------------
nmake /f neon.mak ALL EXPAT_FLAGS="/I ../apr-util/xml/expat/lib /D HAVE_EXPAT /D
HAVE_EXPAT_H" DEBUG_BUILD=Aye
--------------------Configuration: libsvn_subr - Win32 Debug--------------------
Compiling...
config_win.c
d:\work\subversion-0.33.1\subversion\libsvn_subr\config_win.c(47) : error C2065:
'CSIDL_COMMON_APPDATA' : undeclared identifier
d:\work\subversion-0.33.1\subversion\libsvn_subr\config_win.c(48) : error C2065:
'CSIDL_FLAG_CREATE' : undeclared identifier
d:\work\subversion-0.33.1\subversion\libsvn_subr\config_win.c(63) : warning C4013:
'SHGetFolderPathW' undefined; assuming extern returning int
d:\work\subversion-0.33.1\subversion\libsvn_subr\config_win.c(63) : error C2065:
'SHGFP_TYPE_CURRENT' : undeclared identifier
d:\work\subversion-0.33.1\subversion\libsvn_subr\config_win.c(89) : warning C4013:
'SHGetFolderPathA' undefined; assuming extern returning int
Error executing cl.exe.
__ALL__ - 3 error(s), 2 warning(s)
Does anyone know where those missing identifiers are supposed to be defined and why I'm
not finding them?
Patrick Rusk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Rolling Back Changes
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "B" == B W Fitzpatrick <fi...@red-bean.com> writes:
B> Ask bbum what he thinks about tar wrappers. Better yet, search
B> the dev@subversion email archives for his comments. Don't make
B> me bring him over here and *tell* you what he thinks about
B> them. :)
I *know* what he thinks about them. But, he'd be welcome to say hello
here ;)
I am *not* advocating for tar wrappers: it happens that, from my pov,
they already are as opaque as I need them to ;)
B> And all the reasons you state here are why opaque collections
B> are the *correct* way of dealing with this problem. Bundled
B> directories will be dealt with just as you expect them to be
B> dealt with, and on top of that, you don't lose the ability to
B> diff individual files.
Well, I cannot see a reasonable way, but a good configurable
subsystem, that can do that on an universal base: there must be a way
to "ask" the cooperation of the application in charge on the
bundle. And when the application is unwilling/unable to do so, there
must must to a way to circumvent it, ie, tar-it-up and
store-as-is. Given SVN capability of storing binary files, there will
be more and more situation where "diffing individual files" just
doesn't have valuable meaning.
B> Again, I'm not blowing you off here. Please re-read the mail
B> archives where we discussed tar wrappers and opaque collections
B> in the past.
As said, I survived the CVS era storing my nibs inside such deprecated
wrappers, now I'm thankfully waiting what will surely surpass my
sweetest dream on this.
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Rolling Back Changes
Posted by "B. W. Fitzpatrick" <fi...@red-bean.com>.
Lele Gaifax <le...@nautilus.homeip.net> writes:
> >>>>> "Chris" == Chris Parker <ch...@playswithfire.com> writes:
>
> Chris> On Mon, Nov 17, 2003 at 01:00:19AM +0100, Lele Gaifax
> Chris> wrote:
> >> Yes, in ancient NeXT days, there was something like that (was
> >> it CVSPalette?), an IB extension that, using pre/post write
> >> hooks in IB copied .svn/ from the .nib~ folder to the new
> >> .nib/... I remember also a "dirty" hack on CVS modules
> >> functionality, called "wrappers", that in my opinion would be
> >> the right way of dealing with the problem.
>
> Chris> No.
>
> No what?
No way no how no tar wrappers in Subversion. Over my dead body.
> Chris> I can't repeat that enough times. Fitz and a few others are
> Chris> probably wondering just -when- I'm going to read this email
> Chris> and refer you to:
>
> Chris> http://subversion.tigris.org/issues/show_bug.cgi?id=707
>
> Chris> Which would be the Right Way to handle this kind of
> Chris> situation, and get everyone completely away from the
> Chris> wrapper idea.
Yup. I'm a bit behind on my svn email. :)
> I miss your point: issue 707 talks about an "opaque" collection, it
> does not clarify in what way this would be different from the wrapper
> concept. You are apparently against "tar", but I do not see an evident
> reason for which the "storage" of a particular subtree of your repos
> (be it a .nib folder, or a deeper hierachy that, for whatever reasons,
> you want keep zipped+signed in the repository) couldn't be decided by
> the user/developer/admin. I do surely know, by now, that this isn't
> exacly svn' field, but I still consider that some support from it would
> be welcome if not needed.
>
> Chris> People who helped implement the wrapper idea
> Chris> think it's a bad idea. The synchronization issue alone of
> Chris> implementing the wrapper gives most CVS admins fits, and
> Chris> for good reason.
>
> Chris, I do *know*, having used that functionality *while* "people"
> (bbum, primarily) was implementing it :). Sooner or later I will have
> to convert my oldest CVS repos, that used that hack, while the
> NeXTstation keeps booting... :-|
Ask bbum what he thinks about tar wrappers. Better yet, search the
dev@subversion email archives for his comments. Don't make me bring him
over here and *tell* you what he thinks about them. :)
> AFAICT, it was the /implementation/ of the thing that was "dirty", not
> the concept.
Both are dirty.
> Chris> Note that (unfortunately) IB in Panther has the ability to
> Chris> listen for a default for this kind of thing:
>
> Chris> 'defaults write com.apple.InterfaceBuilder
> Chris> VersionControlDirectory "(CVS, .svn)"'
>
> Chris> will allow you to preserve your version control admin
> Chris> directories of choice. You'll still have to manually 'svn
> Chris> add' or 'svn remove' if you put things -in- nibs but IB can
> Chris> at least preserve the directories, limiting the requirement
> Chris> for wrappers use.
>
> Yes, but from a different PoV, this somewhat breaks the admirable
> concept of "app-folders", of which usually the user shouldn't even
> need to know the internal layout. As said, having used it, the
> potential of going out-of-sync is very high ("did I add *every* file
> in the .nib/ folder?" and the like).
Certainly, it's not *perfect*, but it's a reasonable workaround until
someone implements opaque collections.
> Consider the .rtfd/ folders (are those still there?): I can immagine
> that, once I import the first version of the document, I'd prefer that
> in some way svn could understand what I really want: whatever I drop
> in my doc (an image, me saying "hello".snd...), is stored somewhere
> (usually with a serial id as name, not the original) within the .rtfd/
> sub-hierarchy and should be *automatically* considered a "part of the
> document" that was modified. Can you show me a case where you do not
> want to "svn add" that file, *before* committing the folder? Again, I
> know, many think this is a frontend related problem...
And all the reasons you state here are why opaque collections are the
*correct* way of dealing with this problem. Bundled directories will be
dealt with just as you expect them to be dealt with, and on top of that,
you don't lose the ability to diff individual files.
I really hope to see opaque collections implemented in Subversion post
1.0... however, it's most likely going to have to wait until libsvn_wc
is rewritten.
Again, I'm not blowing you off here. Please re-read the mail archives
where we discussed tar wrappers and opaque collections in the past.
-Fitz, who needs to start pasting links to these email discussions into
the 707 issue...
--
Brian W. Fitzpatrick <fi...@red-bean.com> http://www.red-bean.com/fitz/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Rolling Back Changes
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "Chris" == Chris Parker <ch...@playswithfire.com> writes:
Chris> On Mon, Nov 17, 2003 at 01:00:19AM +0100, Lele Gaifax
Chris> wrote:
>> Yes, in ancient NeXT days, there was something like that (was
>> it CVSPalette?), an IB extension that, using pre/post write
>> hooks in IB copied .svn/ from the .nib~ folder to the new
>> .nib/... I remember also a "dirty" hack on CVS modules
>> functionality, called "wrappers", that in my opinion would be
>> the right way of dealing with the problem.
Chris> No.
No what?
Chris> I can't repeat that enough times. Fitz and a few others are
Chris> probably wondering just -when- I'm going to read this email
Chris> and refer you to:
Chris> http://subversion.tigris.org/issues/show_bug.cgi?id=707
Chris> Which would be the Right Way to handle this kind of
Chris> situation, and get everyone completely away from the
Chris> wrapper idea.
I miss your point: issue 707 talks about an "opaque" collection, it
does not clarify in what way this would be different from the wrapper
concept. You are apparently against "tar", but I do not see an evident
reason for which the "storage" of a particular subtree of your repos
(be it a .nib folder, or a deeper hierachy that, for whatever reasons,
you want keep zipped+signed in the repository) couldn't be decided by
the user/developer/admin. I do surely know, by now, that this isn't
exacly svn' field, but I still consider that some support from it would
be welcome if not needed.
Chris> People who helped implement the wrapper idea
Chris> think it's a bad idea. The synchronization issue alone of
Chris> implementing the wrapper gives most CVS admins fits, and
Chris> for good reason.
Chris, I do *know*, having used that functionality *while* "people"
(bbum, primarily) was implementing it :). Sooner or later I will have
to convert my oldest CVS repos, that used that hack, while the
NeXTstation keeps booting... :-|
AFAICT, it was the /implementation/ of the thing that was "dirty", not
the concept.
Chris> Note that (unfortunately) IB in Panther has the ability to
Chris> listen for a default for this kind of thing:
Chris> 'defaults write com.apple.InterfaceBuilder
Chris> VersionControlDirectory "(CVS, .svn)"'
Chris> will allow you to preserve your version control admin
Chris> directories of choice. You'll still have to manually 'svn
Chris> add' or 'svn remove' if you put things -in- nibs but IB can
Chris> at least preserve the directories, limiting the requirement
Chris> for wrappers use.
Yes, but from a different PoV, this somewhat breaks the admirable
concept of "app-folders", of which usually the user shouldn't even
need to know the internal layout. As said, having used it, the
potential of going out-of-sync is very high ("did I add *every* file
in the .nib/ folder?" and the like). Consider the .rtfd/ folders (are
those still there?): I can immagine that, once I import the first
version of the document, I'd prefer that in some way svn could
understand what I really want: whatever I drop in my doc (an image, me
saying "hello".snd...), is stored somewhere (usually with a serial id
as name, not the original) within the .rtfd/ sub-hierarchy and should
be *automatically* considered a "part of the document" that was
modified. Can you show me a case where you do not want to "svn add"
that file, *before* committing the folder? Again, I know, many think
this is a frontend related problem...
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Rolling Back Changes
Posted by Chris Parker <ch...@playswithfire.com>.
On Mon, Nov 17, 2003 at 01:00:19AM +0100, Lele Gaifax wrote:
> Yes, in ancient NeXT days, there was something like that (was it
> CVSPalette?), an IB extension that, using pre/post write hooks in IB
> copied .svn/ from the .nib~ folder to the new .nib/... I remember also
> a "dirty" hack on CVS modules functionality, called "wrappers", that
> in my opinion would be the right way of dealing with the problem.
No.
I can't repeat that enough times. Fitz and a few others are probably
wondering just -when- I'm going to read this email and refer you to:
http://subversion.tigris.org/issues/show_bug.cgi?id=707
Which would be the Right Way to handle this kind of situation, and get
everyone completely away from the wrapper idea. People who helped
implement the wrapper idea think it's a bad idea. The synchronization
issue alone of implementing the wrapper gives most CVS admins fits,
and for good reason.
Note that (unfortunately) IB in Panther has the ability to listen for
a default for this kind of thing:
'defaults write com.apple.InterfaceBuilder VersionControlDirectory
"(CVS, .svn)"'
will allow you to preserve your version control admin directories of
choice. You'll still have to manually 'svn add' or 'svn remove' if you
put things -in- nibs but IB can at least preserve the directories,
limiting the requirement for wrappers use.
.chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Rolling Back Changes
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "kfogel" == kfogel <kf...@collab.net> writes:
kfogel> Why, instead, can't Interface Builder notice the presence
kfogel> of data that it didn't generate, and preserve it? Note
kfogel> that Interface Builder had the same problem with CVS/
kfogel> subdirs, and (if I recall correctly) IB eventually added
kfogel> code to treat them specially. The same thing may happen
kfogel> with .svn/ directories someday. Or maybe Subversion will
kfogel> learn to store metadata differently in the future.
Yes, in ancient NeXT days, there was something like that (was it
CVSPalette?), an IB extension that, using pre/post write hooks in IB
copied .svn/ from the .nib~ folder to the new .nib/... I remember also
a "dirty" hack on CVS modules functionality, called "wrappers", that
in my opinion would be the right way of dealing with the problem.
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Rolling Back Changes
Posted by kf...@collab.net.
Dietrich Epp <di...@zdome.net> writes:
> I don't consider it a problem in Interface Builder. It's just
> something that Interface Builder does that Subversion doesn't
> understand yet. Someday:
>
> svn propset svn:volatile yes *.nib
>
> And I didn't say it was a bug in subversion... but you saw what I
> typed, and you saw what it did. For all I know it was a memory error.
> All I know is that a directory with a handful of files suddenly had
> only one after I committed.
Dietrich, I'm going to have to call you on that one. Your first mail
said:
"I can't even figure out why the files disappeared in the first
place, but I do know that Subversion is entirely to blame."
Now later, after admitting that what probably happened is that
Interface Builder *destroyed Subversion's metadata*, you still feel
that Subversion is "entirely to blame"??
Why, instead, can't Interface Builder notice the presence of data that
it didn't generate, and preserve it? Note that Interface Builder had
the same problem with CVS/ subdirs, and (if I recall correctly) IB
eventually added code to treat them specially. The same thing may
happen with .svn/ directories someday. Or maybe Subversion will learn
to store metadata differently in the future.
But right now, Subversion assumes that its .svn/ areas won't be
destroyed. That's part of the environmental requirements for using
it. If you don't have that kind of environment, then don't use it.
Bad User Experience != Bug,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Rolling Back Changes
Posted by Dietrich Epp <di...@zdome.net>.
On Nov 15, 2003, at 3:36 PM, Ben Collins-Sussman wrote:
> 'svn copy wc URL' and 'svn copy URL URL' won't overwrite things.
> That's
> how we designed things. But 'svn copy URL wc' *should* overwrite
> things, as long as they're scheduled for deletion. It's a regression
> bug that we can't do that anymore. See issue #1516. I'm annoyed about
> it.
There wasn't anything to overwrite.
>> I couldn't reproduce the bug that wiped out my Resources directory.
>
> It's bit presumptious to claim that it was an svn bug that deleted your
> directory... especially since you have no idea how it happened. My
> guess is that you're being smacked by the standard NeXTstep interface
> builder problem: i.e. it's destroying and re-creating whole
> directories
> without telling you.
I don't consider it a problem in Interface Builder. It's just
something that Interface Builder does that Subversion doesn't
understand yet. Someday:
svn propset svn:volatile yes *.nib
And I didn't say it was a bug in subversion... but you saw what I
typed, and you saw what it did. For all I know it was a memory error.
All I know is that a directory with a handful of files suddenly had
only one after I committed.
>> I don't want to deal with merging it. I just want to
>> copy the files back into the directory.
>>
>> Anyway, I just rolled (with dump/load) back to rev 52 and I'm redoing
>> the changes I made since then.
>
> Let me get this straight: dumping and re-loading your whole repository
> is 'easier' than a single 'svn merge -r53:52' command?
>
> OK, whatever floats your boat. :-)
Well, right now I just want to fix the bug that causes my application
to crash when it quits. I know how to copy from old revisions and I
know how to dump and load. I don't want to learn how subversion
handles merging today. Maybe after I fix my bug. It took me mere
moments to make Subversion forget about revisions 53 & 54, then copy
the changes back in. It's not a huge repository -- most of the changes
are in the archived CVS repository. So, yes it was easier than
learning which command to use to merge.
Anyway, I'm content with my repository as it is.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Rolling Back Changes
Posted by Ben Collins-Sussman <su...@collab.net>.
On Sat, 2003-11-15 at 17:26, Dietrich Epp wrote:
> > Run 'svn log -r53 --verbose'. It will list the exact changes made in
> > r53. If you don't like the change, roll it back in your working copy,
> > and commit the "undo" as r54. Read chapter 4 in the book about how to
> > use 'svn merge' to do this.
>
> I was trying to roll back the change by copying the revision 52
> directory into its location.
'svn copy wc URL' and 'svn copy URL URL' won't overwrite things. That's
how we designed things. But 'svn copy URL wc' *should* overwrite
things, as long as they're scheduled for deletion. It's a regression
bug that we can't do that anymore. See issue #1516. I'm annoyed about
it.
> I couldn't reproduce the bug that wiped out my Resources directory.
It's bit presumptious to claim that it was an svn bug that deleted your
directory... especially since you have no idea how it happened. My
guess is that you're being smacked by the standard NeXTstep interface
builder problem: i.e. it's destroying and re-creating whole directories
without telling you.
> I don't want to deal with merging it. I just want to
> copy the files back into the directory.
>
> Anyway, I just rolled (with dump/load) back to rev 52 and I'm redoing
> the changes I made since then.
Let me get this straight: dumping and re-loading your whole repository
is 'easier' than a single 'svn merge -r53:52' command?
OK, whatever floats your boat. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Rolling Back Changes
Posted by Dietrich Epp <di...@zdome.net>.
On Nov 15, 2003, at 12:25 PM, Files wrote:
> Can I see what your file tree looks like from the point at which you
> tried to
> do whatever you did?
>
> On a completely different note, if you want your rev 52 back, you have
> two
> options.
>
> Check out a new copy of rev 52 in a different directory.
>
> Dump and reload everything up to rev 52.
>
> I still don't get exactly what you were attempting to do. Didn't feel
> like
> what you were trying to do was the supposed to be done w/ the commands
> you
> typed.
I'm trying to copy the revision 52 version of
/trunk/Hammer/MacOSX/Resources/English.lproj/
into the working copy. But I guess I could just roll back to rev 52.
The part I don't understand at all is how the contents of the Resources
directory got wiped out. I was in the Resources directory and typed:
$ svn rm MaraLevel2D.nib/
$ svn ci -m 'Temporary.'
I was doing this because I created a new MaraLevel2D.nib. It's a
misfeature in Subversion that when I delete a directory the directory
isn't actually removed until the change is committed, meaning I can't
add a new directory of the same name. This means I have to make two
commits to replace nib files.
I couldn't reproduce the bug that wiped out my Resources directory.
On Nov 15, 2003, at 2:45 PM, Ben Collins-Sussman wrote:
> On Sat, 2003-11-15 at 13:34, Dietrich Epp wrote:
>> I was shocked to find out that most of the files in a directory of my
>> project mysteriously disappeared in revision 53.
>
> Run 'svn log -r53 --verbose'. It will list the exact changes made in
> r53. If you don't like the change, roll it back in your working copy,
> and commit the "undo" as r54. Read chapter 4 in the book about how to
> use 'svn merge' to do this.
I was trying to roll back the change by copying the revision 52
directory into its location. The log just shows the same thing I sent
in the last message, you saw what I typed. I'm not trying to roll back
everything, and I don't want to deal with merging it. I just want to
copy the files back into the directory.
Anyway, I just rolled (with dump/load) back to rev 52 and I'm redoing
the changes I made since then.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Rolling Back Changes
Posted by Files <fi...@poetryunlimited.com>.
Can I see what your file tree looks like from the point at which you tried to
do whatever you did?
On a completely different note, if you want your rev 52 back, you have two
options.
Check out a new copy of rev 52 in a different directory.
Dump and reload everything up to rev 52.
I still don't get exactly what you were attempting to do. Didn't feel like
what you were trying to do was the supposed to be done w/ the commands you
typed.
Can you provide some more info?
--
Shamim Islam
BA BS
Dietrich Epp said:
> I was shocked to find out that most of the files in a directory of my
> project mysteriously disappeared in revision 53. So I tried this:
>
> -----
> $ svn copy file:///path/to/repository/subdir/English.lproj/ . -r 52
> svn: Attempted to lock an already-locked dir
> svn: working copy locked: .
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
> -----
>
> I can't even figure out why the files disappeared in the first place,
> but I do know that Subversion is entirely to blame. Here is some more
> text from my terminal:
>
> -----
> Updated to revision 52.
> $ ls
> English.lproj/ Hammer.icns Level.icns MaraLevel2D.nib/
> MaraLevel3D.nib/
> $ svn rm MaraLevel2D.nib/
> D MaraLevel2D.nib/objects.nib
> D MaraLevel2D.nib/info.nib
> D MaraLevel2D.nib/classes.nib
> D MaraLevel2D.nib
> $ svn ci -m 'Temporary.'
> Replacing Resources
>
> Committed revision 53.
> -----
>
> I'm using subversion 0.33.0. What's with the 'Replacing Resources'?
> (Resources is the directory that the files disappeared from.)
>
> On a side note, it's really ugly working with nib files in subversion.
> When I want to change a nib file, I have to move .svn directories
> around. It would be nice if subversion were smart enough not to put
> .svn directories in nib files or other such places. This is really
> important for Mac OS X developers, I'd rather have no move command than
> have such poor handling of nib files.
>
> On a side, side note... I couldn't find a link to subscribe to this
> list on the project page. I guessed the email address for subscribing.
>
>
>
> ---------------------------------------------------------------------
> 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