harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: Adding new files to SVN and subsequently trying to update
Date Thu, 10 Aug 2006 13:49:17 GMT
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

-- 
Alexei Zakharov,
Intel Middleware Product Division

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