[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#235242: marked as done (tla-load-dirs: making easier to handle large number of files moved)

Your message dated Mon, 14 Mar 2011 09:55:30 +0000
with message-id <[🔎] E1Pz4Us-0000j4-Jc@franck.debian.org>
and subject line Bug#617830: Removed package(s) from unstable
has caused the Debian Bug report #235242,
regarding tla-load-dirs: making easier to handle large number of files moved
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
235242: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=235242
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: tla-load-dirs
Version: 1.0.11
Severity: wishlist

It would be good if there was some better way of handling file renames
when there are are large/huge number of files added/deleted.

For example, when upgrading dar 1.3.0 to dar 2.0.1 (contains major code
rearrangements), it was pure hell, as the entire list was numerous
screens long. Not only did this make it hard to match files, but also
the potential for making mistakes was very high.

To make matters worse, I found it hard to identify if some files had been
moved or if it was a different file with the same filename when manually
checking it.

I don't know the best way of doing this solving this difficult issue,
but some suggestions:

* if filename is the same, but in different directory, the file is
likely to have been moved.

* if file a/x.c was moved to b/x.c, then it is possible a/y.c was also
moved to b/y.c (if b/y.c exists).

* count number of lines different using diff?

Maybe the user interface could somehow be designed to make "most likely"
candidates easier to select by default?

I don't know the best solution, but I hope this provokes some
consideration of the matter...

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.24
Locale: LANG=C, LC_CTYPE=C

Versions of packages tla-load-dirs depends on:
ii  python                        2.3.3-5    An interactive high-level object-o
ii  python2.3                     2.3.3-5    An interactive high-level object-o
ii  tla                           1.1-1      arch revision control system

-- no debconf information

--- End Message ---
--- Begin Message --- 
Version: 1.1.8+rm

Dear submitter,

as the package vcs-load-dirs has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see http://bugs.debian.org/617830

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@debian.org.

Debian distribution maintenance software
pp.
Alexander Reichle-Schmehl (the ftpmaster behind the curtain)

--- End Message ---
Reply to: