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 14:22:20 GMT
On 15/04/2009, Christian Grobmeier <grobmeier@gmail.com> wrote:
> Usecase was:
>  - File A is added
>  - something else
>  - File A is deleted, cause the system has another state now.
>
>  File A must noot be added at all, so delete it from the current
>  ChangeSet and leave it for deletions of an existing stream. I am not
>  sure if there is a Usecaase for this. Definitly it would be more
>  easier without this. However, thinking on applications like VFS (which
>  allready waits for commonos-compress) I don't think that could be
>  impossible.

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.

>  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.

>  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.

Should a file add fail if there is already a matching file, or should
it replace?
Should a file replace fail if there is no matching file, or should it
be treated as an add?

Then there is the question of conditional updates based on datestamps.

>  Christian
>
>
>
>
>
>
>
>
>  On Wed, Apr 15, 2009 at 2:37 PM, sebb <sebbaz@gmail.com> wrote:
>  > The Changeset design seems to me to be a bit assymetric at present.
>  >
>  > ADD changes are just added to the Set of changes; however if a DELETE
>  > is requested, then the existing set is scanned for matching additions
>  > and any such are deleted.
>  >
>  > I'm not sure that is very useful - why would an application want to
>  > add a file and then delete it?
>  >
>  > Also, if an ADD change is added after a DELETE, the delete is left in place.
>  >
>  > I think it would be better if the changes were just added to the set.
>  >
>
> > ---------------------------------------------------------------------
>  > 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
>
>

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


Mime
View raw message