harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: Adding new files to SVN and subsequently trying to update
Date Fri, 11 Aug 2006 06:45:45 GMT
I wrote a perl script to deal with these things:

1. check svn status on some directory
2. execute "svn add" if necessary
3. execute "svn diff" to create diff file
4. create a shell script with "svn add/remove" instructions, which is 
useful for the committer to apply the patch
5. revert to original status

It doesn't remove/rename the new files, but the extension should be 
straightforward. If anyone  has interest, I'm glad to contribute, but 
believe that, I'm a newbie of perl...

Oliver Deakin wrote:
> 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
>>
>


-- 
Paulex Yang
China Software Development Lab
IBM



---------------------------------------------------------------------
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