ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
67916
|
Wed May 20 01:49:37 2015 |
| Konstantin Olchanski | olchansk@triumf.ca | Bug report | Linux | 3.1.0 | elconv deletes everything |
Converting from elog 2.9.something to new elog 3.1.0 elogd refuses to start, instructs running elconv in one logbook.
When I do so, elconv converts a existing mhttpd-style elog entries to the new format (the corresponding new-format entries already exist)
and deletes everything else - this is very bad.
So there are 2 bugs:
- elogd should not tell us to run elconv when both old-style and corresponding new-style elog entries exist
- elconv should not delete all existing new-style elog entries.
I confirm that elconv *does* delete all new-style elog entries - with strace, I see it issue "unlink" on every elog entry.
What a disaster!
K.O. |
67917
|
Wed May 20 01:52:23 2015 |
| Konstantin Olchanski | olchansk@triumf.ca | Bug report | Other | this one | this elog errors sending email |
this elog gives errors sending mail through PSI email server. (did not capture the error messages, sorry). K.O. |
67918
|
Wed May 20 01:54:55 2015 |
| Konstantin Olchanski | olchansk@triumf.ca | Bug report | Other | this one | edit somebody else's draft |
this elog offers me to edit a draft message, then yells at me "only some other user can edit this draft!!!".
methinks I should only be offered to edit draft messages that I own or I can edit. K.O. |
67919
|
Wed May 20 01:59:17 2015 |
| Konstantin Olchanski | olchansk@triumf.ca | Bug report | Linux | 3.1.0 | elogd moves elog entries |
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. |
67920
|
Wed May 20 11:59:59 2015 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Bug report | Linux | 3.1.0 | Re: elogd moves elog entries |
> 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 |
67921
|
Wed May 20 12:52:31 2015 |
| David Pilgram | David.Pilgram@epost.org.uk | Bug report | Linux | 3.1.0 | Re: elogd moves elog entries |
> > 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.
When I first tried v3.0, I wanted to go back due to some bug or feature, and had to do exactly what Andreas suggested above.
David. |
67924
|
Wed May 20 20:03:06 2015 |
| Konstantin Olchanski | olchansk@triumf.ca | Bug report | Linux | 3.1.0 | Re: elogd moves elog entries |
> Stefan told me that the change was because some users were having thousands of yymmdda.log files
> in the logbook directories
I am one of those users. The elog for the ALPHA experiment at CERN goes back to 2006 or so,
with large volume of messages and huge number of attachments. The MIDAS forum elog goes back to 2003.
The TRIUMF DAQ internal elog goes back to 2001.
I think the new organization is an improvement.
K.O. |
67925
|
Wed May 20 22:08:31 2015 |
| David Pilgram | David.Pilgram@epost.org.uk | Bug report | Linux | 3.1.0 | Re: elogd moves elog entries |
> > Stefan told me that the change was because some users were having thousands of yymmdda.log files
> > in the logbook directories
>
> I am one of those users. The elog for the ALPHA experiment at CERN goes back to 2006 or so,
> with large volume of messages and huge number of attachments. The MIDAS forum elog goes back to 2003.
> The TRIUMF DAQ internal elog goes back to 2001.
>
> I think the new organization is an improvement.
>
> K.O.
Hi Konstantin,
I've used elog as my main reference/logbook since 2005. I had looked at it in its version 1 incarnation, but
didn't get on with that so well.
My biggest problem in the past was running elog on two physically separated linux boxes, and for complex reasons
all the logbooks were on a memory stick (plus the vital backup)! Hence my previously mentioned memory issues - in
my case the size of the available memory sticks.
David. |