commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Grobmeier <grobme...@gmail.com>
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.

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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message