On 15/04/2009, Christian Grobmeier <grobme...@gmail.com> wrote: > > If there is a usecase for add then delete, then it seems to me that > > there is likely to be a use case for delete then add. The current code > > only supports the former. > > > Did you see ChangeSetTest.testDeletePlusAdd() ?
Yes. > Is this what you want? No, because the delete and add are for different items. > > >> Then there is the case, that you want to replace an existing entry. > >> You would do it like that: > >> > >> - Delete File A from the current stream > >> - Add File A to the Stream > >> > >> If you don't delete the file, two files with the same name are in one > >> archive, which is bad. > > > > 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 > A bigger problem is, if one adds an entry whcih allready exists in the > stream. That's actually what I meant. > 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. > >> Maybe we hs ould have an Cchange of type == > >> replace which puts those delete change and the add change in order? > > > > One might want to distinguish various different cases. > > > Definitly. > > > > 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. > > 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. > > 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. > --------------------------------------------------------------------- > 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
