r602 - packages/vdrift/vdrift-data/tags/0.0.2006.02.21-1

[Eddy Petrişor]

On 5/5/06, Eddy Petrişor <eddy.petrisor at gmail.com> wrote:
> On 5/5/06, Gonéri Le Bouder <goneri-guest at costa.debian.org> wrote:
> > Author: goneri-guest
> > Date: 2006-05-05 09:13:44 +0000 (Fri, 05 May 2006)
> > New Revision: 602
> >
> > Added:
> >    packages/vdrift/vdrift-data/tags/0.0.2006.02.21-1/rules
> > Log:
> > updated rules file to fix executable-not-elf-or-script
> >
> >
> > Copied: packages/vdrift/vdrift-data/tags/0.0.2006.02.21-1/rules (from rev 600, packages/vdrift/vdrift-data/trunk/debian/rules)
>
> Backporting patches can be done with svn merge[1] more elegantly:
>
> svn co svn+ssh://svn.debian.org/svn/pkg-games/packages/vdrift/vdrift-data/tags/0.0.2006.02.21-1
> cd 0.0.2006.02.21-1
> svn merge -r 600:
> svn+ssh://svn.debian.org/svn/pkg-games/packages/vdrift/vdrift-data/trunk
> svn ci -m "merged the fixperm patch from trunk"

Note that the commit log _should_ contain the merged revisions, so a
more proper message would have been:

"merged the fixperm patch from trunk (r600)"

This is due to the fact that subversion doesn't track the actual
origin of the merged change and the changes are seen as a local
modification merge. So actually someone adding the revision in there
is adding the changeset history which misses from svn.

You can safly ignore the rest of the message if you are not interested
in power-usage of subversion.

<tech fabulate="on">

One could add a special property, let's call it "x-svn:merged" which
could be added to each file/dir which is affected by a merge and store
a list of revisions which were merged in the current revision.

These attributes could be managed (added/modified/removed) once a
merge/unmerge has happened, thus enabling a way to see directly in the
most recent revision what was merged, without looking at the logs.

BUT, all of these would either need an external mechanism/tool to
manage it or manual maintainance, which is no fun ;-)

/me thinks that such a mechianism could be built inside subversion and
could be triggered by some special command or (less sane) the contents
of the commit log (hooks could be  used for this)
</tech>
--
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein