zim-wiki team mailing list archive

[Güven, Ugur Murat <murat.gueven@xxxxxxxxxxxxxx>]

Hi,

just my few cents on this.

I understand that the name of the note is the same as the file name.

What if you introduce a Unique ID (UID) for each note which you add as pre- or suffix to the file name?
You could put this UID into the header of the file e.g. after Creation-Date, as well.

If you add the UID into a separate tree column (column not shown), you could show notes which seem to have the same name, but
are obviously distinguished via the UID.

So any notes which should be archived, can be moved to an ‘archived namespace’ without the need to rename them. I’m not sure
how this conflicts with your current name space hierarchy, but I guess you would need to add this UID as a property to a page as well.

So instead of having:
This is my parent note:Here goes my first child:And here is a sub of my child

You could go with:

UID1:This is my parent note:UID2:Here goes my first child:UID3:And here is a sub of my child

Haven’t thought all implications through though….

Regards,
Murat




From: Zim-wiki [mailto:zim-wiki-bounces+murat.gueven=ts.fujitsu.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jaap Karssenberg
Sent: Donnerstag, 17. September 2015 13:50
To: Zim
Subject: Re: [Zim-wiki] Delete Namespace

Reading over the comments here my proposal would be as follows:
On archive the page (+ subpages + attachments) is renamed to :Archive:parent:page_yyyymmdd(_n)
The "_n" is only used in case this page already exists (because you archived the same page twice on the same day ?).

The date is added to the actual page you archived. Sub-pages remain unaltered. Parents are by definition namespaces with pages but no content of their own.This means that the trunk of the archive reflects the notebook structure while actual archived pages form timestamped branches.
Only conflict I see is when you have pages in your regular notebook that already end in "yyyymmdd". E.g. archiving a sub-page below a parent with such a name will confuse the archive structure. Question is how to address that concern.

One option would be to make the archive timestamp more distinct, e.g. prefixing it with a capital "A". The issue thus remains but becomes more obscure.
Alternative would be to also create a meta-data file that identifies a page as being an archived page and contain the original file name + archive date. That would make it fully robust, but at the cost of more complexity in the file structure. (Btw. this is the way the trash can works on linux systems, so it is a proven concept)

My preference is to not go in the direction of more meta-data for the archive, and rely on convention only. But maybe it is wise to use the special prefix. This make a convention that a file ending in "_Ayyyymmdd" (literal "A", y, m & d to be replaced by date) is interpreted as an archived file.

Anything I overlook ?

Regards,
Jaap


On Tue, Sep 15, 2015 at 8:36 AM, Vlastimil Ott <linux@xxxxxxxxxx<mailto:linux@xxxxxxxxxx>> wrote:
Dne 14.9.2015 v 13:04 Rolf Kleef napsal(a):
first time: create Archive:Foo
second time: create Archive:Foo:2015, perhaps move the first version to
Archive:Foo:2014

Although it starts to feel like a versioning plugin...

We're discussing here a nonstandard situation - how many times you recreate a re-archive a page? The versioning principle is a fallback. Usually you have Page A, Page B, Page A:Subpage A etc. There are no conflicts when moving them around, they have unique names.

Archiving is moving. In case there's an existing page in target namespace you are prompted what to do. Archiving function will decide for you - it'll create a time namespace. Renaming the page would break up the links.

My page is a client project. Subpages, folders, files (documents, images). When I close the project, I archive it. Later if there's another business with the same client, I create a page with the same [client] name. When archiving it, I don't want it to mix up with previous archived page with the same name. So the time name space is the solution. We don't change content, we create metadata. And I can see my work for the client in a chronological view.

--

Vlastimil Ott

www.e-ott.info<http://www.e-ott.info>
www.opensourceblog.cz<http://www.opensourceblog.cz>
@vlastimilott
_______________________________________________
Mailing list: https://launchpad.net/~zim-wiki
Post to     : zim-wiki@xxxxxxxxxxxxxxxxxxx<mailto:zim-wiki@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~zim-wiki
More help   : https://help.launchpad.net/ListHelp