Serendipity Forums

Hi,

I've made a few hacks for my blog, unfortunately, this really complicates upgrading to newer versions of serendipity (I tried it only once - even though I had the changes commited to a local svn repository, the upgrade was a real pain because it was hard to keep track of the changes I did once I unpacked the new release into my working copy - stuff gets moved around, deleted or added... you get the idea).

So I decided to set up a lokal SVK mirror of the serendipity repository, so I can pull changes from the "live" version in svn once a release happens (I don't really need to follow the most recent development).

My question is - which revision/branch should I base my hacks on? I didn't find any indication as to which revision the 1.2.1 release is based on (it hasn't been tagged), patches are regularly backported to the 1.2 branch, some things seem to be backported to the trunk (but there is no indication as to what revisions were merged from where), some things seem to be independently commited to trunk and branch with only the log message giving a clue as to a merge (r2077 + r2078), while other times a single change is commited to both trunk and branch in one revision (r2067).

So - where is development happening, what is the status of the 1.2 branch and what revision should I base my current installation on?

Hi!

So I decided to set up a lokal SVK mirror of the serendipity repository, so I can pull changes from the "live" version in svn once a release happens (I don't really need to follow the most recent development).

That's the best idea, yes.

However, have you ever thought about contributing your patches? Also, what do you need to patch that isn't possible with custom templates or plugins?

My question is - which revision/branch should I base my hacks on? I didn't find any indication as to which revision the 1.2.1 release is based on (it hasn't been tagged), patches are regularly backported to the 1.2 branch, some things seem to be backported to the trunk (but there is no indication as to what revisions were merged from where), some things seem to be independently commited to trunk and branch with only the log message giving a clue as to a merge (r2077 + r2078), while other times a single change is commited to both trunk and branch in one revision (r2067).

Yeah, we rarely use the concept of tagging, because the release process is already quite cumbersome for me.

All recent sub-releases are inside the "branches/1.2/" directory. Some developers only work on 1.2, and I "backport" their change to trunk. Some developers also commit singular files to branch and trunk inside a single commit. I usually seperate those commits. In a small developer group, you can't really unify this method. In the end, it all boils down to the same result, so I don't mind and don't think it'S needed to enforce commit policys.

However, our branches are always a dead-end. If you base your own SVN version on a branch, you will not easily be able to upgrade to a 1.3 version. I strongly recommend to use "trunk" instead?

1.2 is already quite closed. The next release will be 1.3, there is no 1.2.2 sub-release to be expected (unless a major bug or security risk will be discovered).

Regards,
Garvin

garvinhicking wrote: However, have you ever thought about contributing your patches? Also, what do you need to patch that isn't possible with custom templates or plugins?

See bug 1461754. The bug itself is resolved, but I proposed some changes to the way character replacement is handled (I went through the current code, or at least the code back then and it didn't make much sense in some cases). I thought you didn't think it was necessary to change it (or maybe just overlooked my followup), and I didn't press the issue - but I still like to have that change in my version.

Also, I think I had to tweak the czech localization files (partly to work on my webhost and partly due to personal preferences), but this may no longer be necessary in the new version due to the updates by Vláďa.

garvinhicking wrote: However, our branches are always a dead-end. If you base your own SVN version on a branch, you will not easily be able to upgrade to a 1.3 version. I strongly recommend to use "trunk" instead?

Ok, thanks. Which trunk revision do you recommend as "most stable"?

Hi!

See bug 1461754. The bug itself is resolved, but I proposed some changes to the way character replacement is handled (I went through the current code, or at least the code back then and it didn't make much sense in some cases). I thought you didn't think it was necessary to change it (or maybe just overlooked my followup), and I didn't press the issue - but I still like to have that change in my version.

Ah, indeed. I simply missed that. I usually follow these forums more than the bugtracker, simply because users seldomnly made use of it.

But I will try to look into this tomorrow and investigate how we can rectify the situation.

Ok, thanks. Which trunk revision do you recommend as "most stable"?

Currently, the latest revision. There are no known issues with the version in trunk right now.

Regards,
Garvin