commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [COMPRESS] Changeset design
Date Wed, 15 Apr 2009 16:20:41 GMT
On 15/04/2009, Christian Grobmeier <grobmeier@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-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message