copyDiff issue with subfolders (binaryDiff=true)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Publish a set of files with subfolders with binaryDiff=true using this 
artifact pattern (maybe 
others too): artifact 
pattern="ivy/[organisation]/[module]/[revision]/[artifact](.[ext])"

What is the expected output? What do you see instead?
artifacts should be published to LATEST, then copied to folder for [revision] 
but instead copy 
fails.

The path it is trying to copy is a couple of folders deep and the parent 
folders don't exist in the 
destination path so the operation fails.

What version of the product are you using? On what operating system?
SVN Revision: 193
on OS X Leopard (10.5.6)

Please provide any additional information below.
I can't think of a case where, once the LATEST folder in SVN was correctly 
updated with the 
changes, you wouldn't just do a simple svn copy [module]/LATEST 
[module]/[revision].  I've 
hacked the code to do that rather than process the foldersToCopy map and it 
seems to be 
working well in my case.

For some reason I also had to force creation of a new SvnPublishTransaction 
when the module 
name changed (otherwise revision was still pointing to the previous module's).

My hack is very ugly and probably only works for me at the moment (because I 
just need to get 
this functional so I can move on).  I'd prefer to let someone who knows the 
code better make 
these changes if they're the right thing to do but will be happy to send a diff 
showing what I did 
if it helps.

Thanks for a very useful ivy plugin BTW :D

Original issue reported on code.google.com by jgu...@gmail.com on 1 May 2009 at 10:18

[GoogleCodeExporter]

[module] in the above description should really be "the part of your artifact 
access pattern that comes before 
revision".  For instance if your pattern is 
[organisation]/[module]/[branch]/[revision]/[type]s/[artifact].[ext] then 
it should copy [organisation]/[module]/[branch]/LATEST to 
[organisation]/[module]/[branch]/[revision] during 
copyDiff.

Original comment by jgu...@gmail.com on 15 May 2009 at 6:43

[GoogleCodeExporter]

We've never had the need to publish sub-folders (we just publish files) so have 
never
run into this issue. If you could send some more information on how this works
(ivy.xml etc) that would be great. A diff containing your changes would be good 
too.

Original comment by massdosage on 8 Apr 2010 at 2:47

• Changed state: Accepted

[GoogleCodeExporter]

Ah, we use that extensively :)

I've attached an example ivy.xml from an ATG module we build and my diff which 
includes the above hack 
(and the ones for the other issue I posted as well).  I've hard-coded some 
things so it won't work for everyone, 
but it's been getting us by for several months now.

Note my diff is against the following repo state:

URL: http://ivysvn.googlecode.com/svn/trunk
Repository Root: http://ivysvn.googlecode.com/svn
Revision: 205

Original comment by jgu...@gmail.com on 14 Apr 2010 at 4:56

Attachments:

• ivy.xml
• diff.txt

[GoogleCodeExporter]

Is this issue supposed to be fixed in the 2.1.0 release? I'm getting the same 
issue
when publishing a module with artifacts in subfolders to a svn repository with
binarydiff=true. It throws an error stating that 'the directory is out of date'

Setting binarydiff=false serves as a work around for this issue, but I would 
really
like to use binarydiff.

I've attached a sample that highlights the issue. 

Thanks for your help!

Original comment by jmath...@gmail.com on 24 May 2010 at 10:17

Attachments:

• Error.txt
• IvySvnSubfolderError.zip

[GoogleCodeExporter]

jguice - sorry for taking so long to look at this, I just haven't had time. I'm 
working on a IvySvn 2.2.0 release at the moment so I'm going through the old 
issues and would love to include your patch. 

I have managed to write a unit test which reproduces the issue you were having 
with publishing a sub folder. See 
http://code.google.com/p/ivysvn/source/detail?r=251. If you want to try run the 
tests yourself see http://code.google.com/p/ivysvn/wiki/UnitTestSetup.

I also took a look at your patch but found it a bit hard to untangle as it 
looked liked it was solving this issue as well as another one related to having 
a revision in the path. Another difficulty is that the path itself seems broken 
as it contains "+<<<<<<< .mine" lines and is against older source.

If you could submit one patch for this issue that fixes the sub-folder issue, 
against the latest trunk release that would be amazing. I will then take a look 
at that and consider it for inclusion.

I'm happy to accept other fixes but would prefer them in separate issues with 
separate patch files.

Original comment by massdosage on 18 Nov 2010 at 4:18

[GoogleCodeExporter]

No problem, unfortunately we've moved away from SVN as a backing store for the 
ivy repository and we're now using Artifactory.

Yeah, my "patch" was really just a quick hack to make it work for us and as you 
noticed fixed a couple of issues we were having in what I'm sure was a 
less-than-optimal and un-reusable way ;)

Thanks,
Josh

Original comment by jgu...@gmail.com on 18 Nov 2010 at 5:42

[GoogleCodeExporter]

OK, I will leave this issue open until either I have time to look into it, or 
someone else who is having this problem has a go at either integrating the 
relevant bits of your patch or coding up their own fix and supplying it. 

Original comment by massdosage on 23 Nov 2010 at 9:33