Hi, >> Did you see ChangeSetTest.testDeletePlusAdd() ? > > Yes. > >> Is this what you want? > > No, because the delete and add are for different items.
I just added testDeletePlusAddSame() and found out that it works like expected (removes file A and adds file B under the same name as file A). However, this could cause any more trouble if we decide to put the new file on the start of the archive. This is currently not supported. >> > The same problem occurs if one adds a new entry with the same name as >> > an existing entry. This could be checked, but it is not currently >> > done. >> >> True. The ChangeSet doesn't check if the same entry is added twice to it. >> I think the second entry should replace the first. > > This could perhaps be fixed by appropriate choice of equals() implementation Yes good idea. + hashCode, we have discussed it before. When is an ArchiveEntry equal? I think if the name (including any subfolders) and the size is the same. >> A bigger problem is, if one adds an entry whcih allready exists in the >> stream. > > That's actually what I meant. Ah ok i got you now. >> I think the file named A in the ChagneSet should replace the file >> named A which is allready in the stream. > > Maybe, see below - there are other possible options. > >> > Should a file add fail if there is already a matching file, or should >> > it replace? >> >> Thinking on Windows Explorer, I think it should replace. Or maybe >> leave this option to the user with an param in ChangeSet? Default = >> replace, failOnDuplicate() = fail? > > I agree the default should be to replace, but it might be useful to > allow the caller to choose - or at least to know what actually > happened. I agree >> > Should a file replace fail if there is no matching file, or should it >> > be treated as an add? >> >> I think add. > > I agree the default should be add, but it might be useful for the > caller to know whether or not an existing file was replaced. How can he know besides if he chooses what to do? >> > Then there is the question of conditional updates based on datestamps. >> >> Does every archive provide datestamps? > > Some do. > > If some don't, then for those one could assume that the exisiting copy is > older. OK Thanks for your review, i really appreciate it! Christian --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
