Hi Alex,
I think you can't just delete the file once youve done an "svn add" on it.
I think svn stores some metadata (I believe in the .svn/entries file) about
the files you've added, and so doing a plain delete of the file without
telling
svn will leave the metadata laying around. Normally if I want to remove a
file I have added so I can update, I will revert the file add (so it is
no longer
revision controlled) and then delete it before updating.
Now that you have deleted the file, you can still run an svn revert to
remove
the metadata related to the file addition - just revert the containing
directory,
and only pick the JustResources.pack file.
Unfortunately I do not have a better solution to this problem - it is a
pain,
but I dont know of any better way to do it :(
Regards,
Oliver
Alex Blewitt wrote:
Can't even friggin delete it ...
apple[pack200] svn up
subversion/libsvn_wc/update_editor.c:1541: (apr_err=155000)
svn: Failed to add file 'JustResources.pack': object of the same name
is already scheduled for addition
On 10/08/06, Alex Blewitt <[EMAIL PROTECTED]> wrote:
One thing that annoys me is when I submit new files, and do an update,
I get a message:
apple[pack200] ls
HelloWorld.pack JustResources.pack
apple[pack200] svn up
subversion/libsvn_wc/update_editor.c:1520: (apr_err=155000)
svn: Failed to add file 'JustResources.pack': object of the same name
already exists
The normal answer/faq "The case is wrong" doesn't apply -- I've got a
case sensitive file system. The problem is that the JustResources.pack
doesn't exist on the SVN branch that I'm working on at the moment, but
someone else has added it for me; and when I try update to their copy,
I get this message.
Surely SVN can't be dozy enough that it doesn't realise that the
file's contents is exactly the same in this case, and/or offer to try
and merge it? Is there some kind of --stop-being-anal flag that I need
to pass to SVN to convince it to do the work properly?
The wisdom of 'well, just delete the file and update' is all well and
good, but (a) I want to check that the file's been added properly, and
(b) see if any changes have been made between the patch that I sent up
and what's currently in SVN. If I just delete it, I'm taking it on
faith that it's the same as it was before (and, for that matter, that
it's been added successfully).
It's also a right pain when it's not just one or two, but perhaps a
handful (7) of new files.
Is there any way of configuring either the command-line update or
subclipse to get it right, or am I doomed to this process every time I
create a new file?
Alex.
On 10/08/06, Mikhail Loenko (JIRA) <[EMAIL PROTECTED]> wrote:
> [ http://issues.apache.org/jira/browse/HARMONY-1019?page=all ]
>
> Mikhail Loenko resolved HARMONY-1019.
> -------------------------------------
>
> Resolution: Fixed
>
> Alex,
> the patch was applied in revision 430314
> missing copyrights were added to the new files
> please let me know if it's OK for you
>
> > Adding RunCodec and segment encoding tests
> > ------------------------------------------
> >
> > Key: HARMONY-1019
> > URL:
http://issues.apache.org/jira/browse/HARMONY-1019
> > Project: Harmony
> > Issue Type: Improvement
> > Components: Classlib
> > Reporter: Alex Blewitt
> > Assigned To: Mikhail Loenko
> > Priority: Minor
> > Attachments: patch, patch.txt, patch3.txt,
PopulationCodec.java
> >
> >
> > This adds some functionality to the pack200 implementation,
albeit not used at present. The codec encoding allows multiple codecs
to be specified by decompressing values from the header bytes;
eventually, this will be needed by the segment decoding (currently,
they all assume a default encoding for each band).
> > Note to whoever applies this fix: please apply this fix as-is
first (and commit) and then apply any typographical
fixes/renames/spaces and commit a second time. It's a real nightmare
trying to update-and-merge code after I've submitted it and minor
changes have been made to this patch file prior to committing. At
least if you commit it as is first, I can then easily update to that
version and then merge upwards to take into account your changes
automatically. Thanks!
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the
administrators: http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
http://www.atlassian.com/software/jira
>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
