harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: Adding new files to SVN and subsequently trying to update
Date Thu, 10 Aug 2006 15:47:52 GMT
I use TortoiseSVN also - I just tested it out by creating a dummy
modules\tools\src\main\java\org\apache\harmony\tools\keytool\KeyCertGenerator.java
file and trying to update to pick up Mikhails latest changes (which add
this file to the repository). Unfortunately TortoiseSVN gives me an
error stating "object of the same name already exists".

If I delete the file and then try to update, I get another error stating
"object of the same name is already scheduled for addition", so it
looks like I still have to revert before the update, even with
TortoiseSVN.

Regards,
Oliver

Alexei Zakharov wrote:
> I use graphical TortoiseSVN client and do not remember much pain with
> file addition. It seems TortoiseSVN does some part of the stupid job
> by itself. I believe there should be something like it on *NIX too.
>
> Regards,
>
> 2006/8/10, Oliver Deakin <oliver.deakin@googlemail.com>:
>> Alex Blewitt wrote:
>> > Yeah ... the problem is that unless you do an 'svn add', it doesn't
>> > show up when you have an 'svn patch' or similar (see other swearing,
>> > ranting etc. about missing files). So, I've got to add, patch, submit,
>> > wait, hack/revert, diff each new file I add ...
>>
>> Yeah, if you want the file to appear in the patch, then you've got to
>> add it.
>> Then once you do that you can't update, ugh! I guess you could not do
>> the svn add and just attach the files to the JIRA along with the patch
>> and describe where they should go, but this takes more effort on the
>> part of the committer to put them in the right place and is open to
>> mistakes when writing down the path locations of the files (which can
>> be pretty long in Harmony!).
>>
>> >
>> > The big problem (for me) is that it effectively means once I've added
>> > a new file, I really can't do any new work on it until it's been
>> > added, since otherwise any changes I make between filing the patch and
>> > having a clean 'svn up' (which I have just got to -- hooray!) are
>> > almost certain to be lost in the process. In turn, it means that
>> > there's much less of a benefit to me submitting code in smaller
>> > chunks, and I might as well just sit on it until I've developed a huge
>> > wodge of changes and send them in one go.
>>
>> If you are following the add, create patch, revert, delete, update, diff
>> cycle, then
>> at least you can transfer new changes to the svn versioned file during
>> the diff stage, so you should be able to continue working on the 
>> newly added
>> file (even if it is a hassle every time you have to update).
>> I would be great if svn would recognise that the added file in the 
>> repo was
>> the same as the one added on your disk and attempt to merge them.
>>
>> There must be someone out there who knows a better way to do this?
>>
>> Regards,
>> Oliver
>>
>> >
>> > Mind you, it's not like we're working against a deadline here, and I'm
>> > happy taking a few days off from thinking about it ... but I'll plan
>> > where my breaks are better in terms of functionalitiy in the future.
>> >
>> > (Any SVN developers on this list want to help figure out how to make
>> > this better?)
>> >
>> > Alex.
>> >
>> > On 10/08/06, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
>> >> Just sent my other mail before seeing this one.
>> >> Rather than manually editing the entries file you can, as I suggest
>> >> in the
>> >> other mail, still revert the original file name after you have moved
>> >> it to
>> >> a new file.
>> >>
>> >> So you could:
>> >>  - move the file to a new name AddedFile.java.bak
>> >>  - svn revert AddedFile.java (this should still work even tho the 
>> file
>> >> is no longer there)
>> >>  - svn up
>> >>  - compare AddedFile.java and AddedFile.java.bak
>> >>  - swear etc.
>> >>
>> >> Hope this helps,
>> >> Oliver
>> >>
>> >>
>> >> Alex Blewitt wrote:
>> >> > 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
>> >> > <entry
>> >> >   name="AddedFile.java"
>> >> >   kind="file"
>> >> >   schedule="add"
>> >> >   revision="0"/>
>> >> > 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
>> >> > entries)
>> >> > 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.
>> >> >
>> >> > Alex.
>> >> >
>> >> > On 10/08/06, Alex Blewitt <alex.blewitt@gmail.com> 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 <alex.blewitt@gmail.com> 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) <jira@apache.org>
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
>> >> --
>> >> Oliver Deakin
>> >> IBM United Kingdom Limited
>> -- 
>> Oliver Deakin
>> IBM United Kingdom Limited
>

-- 
Oliver Deakin
IBM United Kingdom Limited


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message