Fwd: Re: Adding new files to SVN and subsequently trying to update
Mark Phippard very kindly took on board my comments, and added a FAQ to subversion as well as raising an issue for this. A couple of things are worth noting: 1) I should have used 'svn revert' rather than editing the entries file by hand. mv new.file new.file.old; svn revert new.file will apparently do the work 2) A new subversion option --force is in the works (svn 1.5), which will overwrite any local changes. It only applies to update files, but if the below issue is addressed it should allow for added files too. However, I think that the --force will discard any local changes, even if you've made subsequent edits since the patch was fled, so it might still be an idea to rename it to a separate file so that you can do manual diff checks. Thanks, Mark! Alex. -- Forwarded message -- From: Mark Phippard Date: 12-Aug-2006 14:04 Subject: Re: Re: Adding new files to SVN and subsequently trying to update To: Alex Blewitt OK, the FAQ has been added: http://svn.collab.net/viewvc/svn?view=revrevision=21056 http://subversion.tigris.org/faq.html#obstructed-add And also an issue has been filed: http://subversion.tigris.org/issues/show_bug.cgi?id=2593 Thanks Mark - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding new files to SVN and subsequently trying to update
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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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
Re: Adding new files to SVN and subsequently trying to update
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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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
Re: Adding new files to SVN and subsequently trying to update
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: http://issues.apache.org/jira/secure/Administrators.jspa - 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]
Re: Re: Adding new files to SVN and subsequently trying to update
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 [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
Re: Adding new files to SVN and subsequently trying to update
Hi Alex, I think you can't just delete the file once youve done an svn add on it. I think svn stores some metadata (I believe in the .svn/entries file) about the files you've added, and so doing a plain delete of the file without telling svn will leave the metadata laying around. Normally if I want to remove a file I have added so I can update, I will revert the file add (so it is no longer revision controlled) and then delete it before updating. Now that you have deleted the file, you can still run an svn revert to remove the metadata related to the file addition - just revert the containing directory, and only pick the JustResources.pack file. Unfortunately I do not have a better solution to this problem - it is a pain, but I dont know of any better way to do it :( Regards, Oliver Alex Blewitt 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: http://issues.apache.org/jira/secure/Administrators.jspa - 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] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL
Re: Adding new files to SVN and subsequently trying to update
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 [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
Re: Adding new files to SVN and subsequently trying to update
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 [EMAIL PROTECTED] 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 [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
Re: Adding new files to SVN and subsequently trying to update
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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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 [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
Re: Adding new files to SVN and subsequently trying to update
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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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.
