Bug#408611: svn-arch-mirror: fails to sync a doubly checked out source tree

2007-01-29 Thread Jean-Marc Notin

2007/1/27, Lionel Elie Mamane <[EMAIL PROTECTED]>:

To my regret, svn-arch-mirror is just that: A utility to mirror a svn
repository and/or branch into a tla category / branch. Not to
synchronise changes that happened in both, but to mirror changes that
happened in svn into GNU Arch.


I am well aware of that, and is exactly what i need :-)
All i want to do running 'svn-arch-mirror sync' is to synchronize
changes in the svn repository to the tla branch. And it used to work
this way perfectly. But not anymore...

--
Jean-Marc Notin


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#408611: svn-arch-mirror: fails to sync a doubly checked out source tree

2007-01-29 Thread Lionel Elie Mamane
On Mon, Jan 29, 2007 at 11:52:24AM +0100, Jean-Marc Notin wrote:
> 2007/1/27, Lionel Elie Mamane <[EMAIL PROTECTED]>:

>> To my regret, svn-arch-mirror is just that: A utility to mirror a
>> svn repository and/or branch into a tla category / branch. Not to
>> synchronise changes that happened in both, but to mirror changes
>> that happened in svn into GNU Arch.

> I am well aware of that, and is exactly what i need :-) All i want
> to do running 'svn-arch-mirror sync' is to synchronize changes in
> the svn repository to the tla branch.

It does not synchronise anything, it mirrors a svn branch as a tla
branch. As in: a situation where there is a monotone bijection between
the revisions of both branches.

Either we have a profound disagreement about what it is that
svn-arch-mirror currently does or I don't understand what you are
trying to say.

What do you expect svn-arch-mirror to do? Rollback the changes made by
tla and force the next tla revision to be exactly the svn revision?
Keep the tla changes and abandon the idea that a svn revision can be
found as is on the tla side?

> And it used to work this way perfectly.

It used to work in a previous version? It used to work in a different
situation (e.g. no changes commited to the tla branch except by
svn-arch-mirror) where our differing interpretations don't lead to any
observable (behaviour) difference? Please specify.

-- 
Lionel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#408611: svn-arch-mirror: fails to sync a doubly checked out source tree

2007-01-29 Thread Jean-Marc Notin

It does not synchronise anything, it mirrors a svn branch as a tla
branch. As in: a situation where there is a monotone bijection between
the revisions of both branches.


I am afraid i was mistaken about what svn-arch-mirror can do. I
thougth it was able to synchronize the tla branch in a more elaborate
way. My mistake.


What do you expect svn-arch-mirror to do? Rollback the changes made by
tla and force the next tla revision to be exactly the svn revision?
Keep the tla changes and abandon the idea that a svn revision can be
found as is on the tla side?


I wish svn-arch-mirror could backtrack the tla revisions, synchronize
the tla tree with the svn repository, and replay the local tla
revisions. I realize that it would be not so easy to handle conflicts
with such an automatic feature of svn-arch-mirror...

Now, i guess the right thing to do is to apply the protocol you
described in your previous email.

Thank you for your help !

--
Jean-Marc Notin


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Processing of noffle_1.2.0~rc1-5_i386.changes

2007-01-29 Thread Archive Administrator
noffle_1.2.0~rc1-5_i386.changes uploaded successfully to localhost
along with the files:
  noffle_1.2.0~rc1-5.dsc
  noffle_1.2.0~rc1-5.diff.gz
  noffle_1.2.0~rc1-5_i386.deb

Greetings,

Your Debian queue daemon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



noffle_1.2.0~rc1-5_i386.changes ACCEPTED

2007-01-29 Thread Debian Installer

Accepted:
noffle_1.2.0~rc1-5.diff.gz
  to pool/main/n/noffle/noffle_1.2.0~rc1-5.diff.gz
noffle_1.2.0~rc1-5.dsc
  to pool/main/n/noffle/noffle_1.2.0~rc1-5.dsc
noffle_1.2.0~rc1-5_i386.deb
  to pool/main/n/noffle/noffle_1.2.0~rc1-5_i386.deb


Override entries for your package:
noffle_1.2.0~rc1-5.dsc - source news
noffle_1.2.0~rc1-5_i386.deb - optional news

Announcing to debian-devel-changes@lists.debian.org
Closing bugs: 408553 


Thank you for your contribution to Debian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



playground REMOVED from testing

2007-01-29 Thread Debian testing watch
FYI: The status of the playground source package
in Debian's testing distribution has changed.

  Previous version: 0.3-1
  Current version:  (not in testing)
  Hint: 
#20070121
Bug #407575: playground does basically nothing

The script that generates this mail tries to extract removal
reasons from comments in the britney hint files. Those comments
were not originally meant to be machine readable, so if the
reason for removing your package seems to be nonsense, it is
probably the reporting script that got confused. Please check the
actual hints file before you complain about meaningless removals.

-- 
This email is automatically generated; [EMAIL PROTECTED] is responsible.
See http://people.debian.org/~henning/trille/ for more information.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



playground-xmms REMOVED from testing

2007-01-29 Thread Debian testing watch
FYI: The status of the playground-xmms source package
in Debian's testing distribution has changed.

  Previous version: 0.3-1
  Current version:  (not in testing)
  Hint: 
#20061226
Bug #403978: playground-plugin-xmms doesn't work

The script that generates this mail tries to extract removal
reasons from comments in the britney hint files. Those comments
were not originally meant to be machine readable, so if the
reason for removing your package seems to be nonsense, it is
probably the reporting script that got confused. Please check the
actual hints file before you complain about meaningless removals.

-- 
This email is automatically generated; [EMAIL PROTECTED] is responsible.
See http://people.debian.org/~henning/trille/ for more information.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]