OK, so for anyone else reading this thread (or googling for 'object of
the same name already exists'):

1) If it's a case insensitive filing system (e.g. Windows) then see
the Subversion FAQ: http://subversion.tigris.org/faq.html
2) If it's a case senstive filing system, and the case is right, and
you're adding a new file to an open-source project and someone's
already committed that and you're trying to update to pretty much the
same file:

2a) Move the old file to a new name (e.g. mv AddedFile.java
AddedFile.java.bak or rename AddedFile.java AddedFile.java.bak)
2b) Go into the .svn directory, and open up the file 'entries'
2c) Where there is an entry like
then delete it from the entries file. It may well be marked as
read-only, so you'll either have to edit it on something that ignores
the readonly flag or mark it r/w first (chmod +w entries or attrib -r
2d) svn up AddedFile.java (which brings it in)
2e) Diff AddedFile.java AddedFile.java.bak if you want to see what the
changes are
2f) Delete AddedFile.java.bak since it's no longer necessary.

Repeat 2a-2f for as many new files as you've added. Swear, drink
caffeinated/alchoholic beverage of your choice, and vow to add as few
new files as possible in the future by writing humungous class files.

Hope that's useful to anyone else in this position.


On 10/08/06, Alex Blewitt <[EMAIL PROTECTED]> 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: 
> > -
> > 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]

Reply via email to