Hi,
I made several changes.
- two files with the same name cannot added to the ChangeSet
- An "add change" command can have a replace = true or replace = false
flag. If true, the add will be added to the stream first. Equal
entries from the stream will be skipped. If false, the stream entrie
will be copied, and then it will be checked if the change can be
applied or not
- two entries with the same name in the stream are not possible any longer
- the ChangeSetPerformer.process method returns a Result object with
several lists of filenames. A user can see where the entries came from
- some tests for this
- added equals methods and hashCode to the ArchiveEntrys for the features above
This should address most problems in this thread - comments welcome!
Cheers,
Christian
On Thu, Apr 16, 2009 at 5:13 PM, Christian Grobmeier
<grobme...@gmail.com> wrote:
>>> 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.
>
> Yes.
>
> If you make Add and Delete, the Add to a stream should never happen,
> cause you simply cannot delete it later.
>
> If Delete and Add, you have the Deletion from a Stream and an addition
> later. I don't think this order should remove the add, just because
> you called delete before.
>
> I imagine it like commandline.
>
> If you have:
>
>> add file
>> delete file
>
> you have nothing in the stream.
>
> If you make:
>
>> delete file
>> add file
>
> then you have the latest addition in the stream.
>
> Do you think this is bad behaviour?
>
>>> 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.
>
> Ah yes, of course, adds first. I had the wrong code in my head. Adds
> are processed first.
>
>>> 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.
>
> don't know if it's important, but if one makes:
>
> if(entry.equals(other)) {
> out.putArchiveEntry(entry);
> } else {
> out.putArchiveEntry(other);
> }
>
> I think this is a very obscure usecase and cannot mind anything,
> so I think you are right and we should go on with same name, same entry.
>
>>> 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.
>
> A returned list of actually processed files would surely be cool.
>
> Cheers
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
