commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Grobmeier <>
Subject Re: [COMPRESS] Changeset design
Date Thu, 16 Apr 2009 15:13:30 GMT
>> 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.


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)) {
} else {

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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message