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 Fri, 11 Aug 2006 08:42:49 GMT
Hi,

I did not say that it solves all problems, but at least you do not
need to do "svn add" each time you add a new file and want to create a
patch.

Regards,

2006/8/10, Oliver Deakin <oliver.deakin@googlemail.com>:
> 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
>
>


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