> Seriously, I really hope It could make it... Could you try it on your side ?

My personal opinion here is, that if you want others to investigate your problems, then the best way to do it is like that:
- attach a minimal configuration that reproduces your problem (never attach a 100 line configuration, unless you've tested that the problem disappears
regardless of which line you remove!);
- attach the entry data, if the behaviour depends on the data;
- use a specific, to the point subject line;
- explain what you did, what happened and what you would have expected to happen;
- ask kindly; and then
- wait and hope for the best ;-)

(This is actually a very general procedure; I think it is applicable to all newsgroups, forums, etc.)

BTW: This tip was absolutely free of charge ;-)

> I came accross the admin guide and I was reading / searching for a way to sync logbooks across sites...
> elogd mention "-m" and "-M" ... not elog but elogd... with that description :
> synchronize logbook(s) with remote server

If you would have followed the shown link to the "elogd.cfg syntax page", you would have found the chapter Mirroring:
https://midas.psi.ch/elog/config.html#mirroring

> Does it sync all logbooks ? 

Not necessarily, but that is the default.

> is there any examples somewhere or advice ?

See above: you'll find examples under #mirroring

> Thanks :)

You're welcome.

> elogd 3.1.0 moves all elog entries into year-named subdirectories. this feature makes it incompatible with older elogs and so should be clearly mentioned in the documentation,
> in the release announcement and in the release and migration notes. K.O.

That feature is one of the main reasons why the version jumped from 2.x to 3.x. 
A free tip: changes in major revisions do indicate some kind of incompatibility.
But yes, the release documentation by bitbucket is not really that useful: 
it is difficult for me too, to find out what changed with new releases. 
I have to admit here, that I haven't read any GIT tutorial yet.
By the way: you are welcome to contribute to the release documentation!

On your actual problem: to go back to a former version of ELOG you can simply
- stop elogd 3.X, 
- move all entries from the sub-directories one level up, and 
- start the 2.X version of elogd.

I wouldn't really call this an "incompatibility", would you? 
At least you can easily go back without much trouble.

Cheers
Andreas

> Stefan told me that the change was because some users were having thousands of yymmdda.log files
> in the logbook directories, and that sorting them into subdirectories by year at least did something to bring some 
> order.  Possibly to get around the lazy archivers, I suspect.

I'm actually the culprit, who did ask for it.

If you want to know the full story, here it is:
We have our logbook data of our accelerator operation logbooks on AFS (Andrew File System). 
And apparently AFS has a bloody stupid, hard coded limit: 
the total length of all file names in one directory cannot exceed 64k.
Our operation logbooks go back for more than a decade and do contain many, many, many attachment files.
One day - very unexpectedly - we did hit that limit. 
Removing temporary files (generated picture thumbnails) bought us time, and Stefan was nice enough to upgrade ELOG swiftly for us: a big "Thank You" to Stefan!

I had no intention of causing any offence with my lazy archiving comment - hope I didn't, sorry if I did.

Personally, I would have found it useful to put the attachments into a separate directory - or at least to allow

the possibility. Elog as it stands sometimes can, and sometimes cannot cope with that functionality - and even to try means messing around directly with the

yymmdda.log files. For me it would have saved me having duplicates of the same large attachment in two or three different logbooks, if I could always reference

the same Master copy of the attachment. This was at the time I was severely memory constrained, and in part forced me to change how I had operated elog, so for

me that need isn't as great as it once was.

David.

You can put a reference to the attachment of the other entry in your logbook: elog:67896/1

> > elogd 3.1.0 moves all elog entries into year-named subdirectories. this feature makes it incompatible with older elogs and so should be clearly mentioned in the documentation,
> > in the release announcement and in the release and migration notes. K.O.
> 
> But yes, the release documentation by bitbucket is not really that useful: 
> it is difficult for me too, to find out what changed with new releases. 

I did know that I've read it summarized somewhere!
The changes with the different releases are documented here:
http://midas.psi.ch/elog/download/ChangeLog

It is actually not so difficult to find: 
it is linked on the "Download" section http://midas.psi.ch/elog/download.html

"News for each version can be seen in the changelog (->http://midas.psi.ch/elog/download/ChangeLog)"

And for version 3.0.0 it states:
- Create one logbook subdirectory pear year

I admit that version 3.0 has never been announced and the changelog is not mentioned in the announcement of version 3.1.0
Maybe we'll do better in the future ;-)