Bug 55759

Summary:	[file backend] REV property is messed up in vCard
Product:	SyncEvolution	Reporter:	Ildar Muyukov <ildar>
Component:	SyncEvolution	Assignee:	SyncEvolution Community <syncevolution-issues>
Status:	RESOLVED DUPLICATE	QA Contact:
Severity:	normal
Priority:	medium	CC:	ildar, syncevolution-issues
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Ildar Muyukov 2012-10-08 11:41:56 UTC

having something synced to the file backend makes numbered files with 
REV:20100328T103410Z
So original mtime is lost.

Comment 1 Patrick Ohly 2012-10-08 13:17:26 UTC

Updating REV is part of converting between remote and local format. It's by design. A "raw file source" would avoid that, see #52791.

*** This bug has been marked as a duplicate of bug 52791 ***

Comment 2 Ildar Muyukov 2012-10-09 04:41:56 UTC

(In reply to comment #1)
> Updating REV is part of converting between remote and local format. It's by
> design.

I don't see a good reason for this decision. You lose REV info to store a value that could be stored in X-Whatever property. Ok, that's minor, I think.

> A "raw file source" would avoid that, see #52791.

Sure, when it's ready.

Comment 3 Patrick Ohly 2012-10-09 06:35:57 UTC

The design decision is that the engine stores a vCard that is not the one that it received. Instead, conceptually, it stores the result of merging local and remote data, which may lead to a different result and thus requires bumping the REV string.

The "cache data in local file" is a special case where no merging happens, but it still follows the same rules in the engine. Changing that requires a different approach.

Comment 4 Ildar Muyukov 2012-10-09 06:45:57 UTC

IC, thanks.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.