On 16/04/2009, Christian Grobmeier <grobme...@gmail.com> wrote: > 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, it does not work exactly the same as Add then Delete, because that removes all trace of the Add from the Set. > 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. > Huh? AFAIK, that is what happens now - adds are processed first. > > >> > 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. > Not sure size is relevant. Most archivers will have problems coping with multiple entries with the same name. > > >> 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? > Either an Exception is thrown if the archive was not in the expected state, or the process() method needs to return a list of what was actually processed. > >> > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
