Source control: Scanning for changes

[Edwin Vane-3]

Hi,

If I'm in a directory managed by source control and I type 'meld .' at
the command line, I find that meld seems to scan the entire directory
structure (starting from the repo root even if I'm in a subdirectory)
looking for changes. Two questions:

1) Why does meld scan from root every time? Should it not just scan
starting from the directory it was invoked from?
2) Why does meld manually scan for changes when it can rely on the
source control itself (e.g. svn st or hg st) to get a list of files?

I'm just curious if there are good reasons for these behaviours. Maybe
there aren't good reasons and they're just something that can be
fixed/improved.

I'm using meld 1.3.

--
Edwin V
_______________________________________________
meld-list mailing list
meld-list@...
http://mail.gnome.org/mailman/listinfo/meld-list

[Stephen Kennedy]

> If I'm in a directory managed by source control and I type 'meld .' at
> the command line, I find that meld seems to scan the entire directory
> structure (starting from the repo root even if I'm in a subdirectory)
> looking for changes. Two questions:
>
> 1) Why does meld scan from root every time? Should it not just scan
> starting from the directory it was invoked from?

Hi Edwin, in previous versions the behavior was as you would expect
(you just see from the subdirectory down). The vc plugins have been
tidied and refactored in 1.3 and this must have slipped in.

I've attached a hack which works-for-me. In the meanwhile can you
open a bug?

> 2) Why does meld manually scan for changes when it can rely on the
> source control itself (e.g. svn st or hg st) to get a list of files?

I don't understand this one, meld generally parses the vc status command
output to detect file states.

Stephen.
_______________________________________________
meld-list mailing list
meld-list@...
http://mail.gnome.org/mailman/listinfo/meld-list

[Vincent Legoll]

On Thu, Jul 2, 2009 at 1:12 AM, Stephen Kennedy<stevek@...> wrote:

>> If I'm in a directory managed by source control and I type 'meld .' at
>> the command line, I find that meld seems to scan the entire directory
>> structure (starting from the repo root even if I'm in a subdirectory)
>> looking for changes. Two questions:
>>
>> 1) Why does meld scan from root every time? Should it not just scan
>> starting from the directory it was invoked from?
>
> Hi Edwin, in previous versions the behavior was as you would expect
> (you just see from the subdirectory down). The vc plugins have been
> tidied and refactored in 1.3 and this must have slipped in.

I'll have a look at this

> I've attached a hack which works-for-me. In the meanwhile can you
> open a bug?

Care to share the hack ?

>> 2) Why does meld manually scan for changes when it can rely on the
>> source control itself (e.g. svn st or hg st) to get a list of files?
>
> I don't understand this one, meld generally parses the vc status command
> output to detect file states.

Meld scans all of the tree recursively, even if only one file is checked
out/modified, this can be very long...

--
Vincent Legoll
_______________________________________________
meld-list mailing list
meld-list@...
http://mail.gnome.org/mailman/listinfo/meld-list

[Edwin Vane-3]

Hi,

Sorry for the delay. I've been away on vacation and I forgot
completely about this issue.

On Wed, Jul 1, 2009 at 7:12 PM, Stephen Kennedy<stevek@...> wrote:
>
>> 2) Why does meld manually scan for changes when it can rely on the
>> source control itself (e.g. svn st or hg st) to get a list of files?
>
> I don't understand this one, meld generally parses the vc status command
> output to detect file states.
>

As Vincent just mentioned, meld seems to recursively go through the
entire directory tree looking for changes. I'm guessing it's just
calling the source control's 'status' command in each directory.
However, with large directory structures this can take a long time. I
sometimes have a non-versioned subtree within the directory structure
(created as part of the build) and searching these things is really
unnecessary. In my experience with svn and mercurial, just calling the
'st' command in the root directory automatically shows all changes in
subdirectories. In theory, meld can just use this list instead of
recursively traversing the directory structure looking for changes.

--
Edwin V
_______________________________________________
meld-list mailing list
meld-list@...
http://mail.gnome.org/mailman/listinfo/meld-list

[Vincent Legoll]

On Thu, Jul 16, 2009 at 3:15 PM, Edwin Vane<revane@...> wrote:

>> I don't understand this one, meld generally parses the vc status command
>> output to detect file states.
>
> As Vincent just mentioned, meld seems to recursively go through the
> entire directory tree looking for changes. I'm guessing it's just
> calling the source control's 'status' command in each directory.
> However, with large directory structures this can take a long time. I
> sometimes have a non-versioned subtree within the directory structure
> (created as part of the build) and searching these things is really
> unnecessary. In my experience with svn and mercurial, just calling the
> 'st' command in the root directory automatically shows all changes in
> subdirectories. In theory, meld can just use this list instead of
> recursively traversing the directory structure looking for changes.

I think some VC plugins do it this way, but not all of them

--
Vincent Legoll
_______________________________________________
meld-list mailing list
meld-list@...
http://mail.gnome.org/mailman/listinfo/meld-list

[Edwin Vane-3]

On Thu, Jul 16, 2009 at 9:34 AM, Vincent Legoll<vincent.legoll@...> wrote:

> On Thu, Jul 16, 2009 at 3:15 PM, Edwin Vane<revane@...> wrote:
>>> I don't understand this one, meld generally parses the vc status command
>>> output to detect file states.
>>
>> As Vincent just mentioned, meld seems to recursively go through the
>> entire directory tree looking for changes. I'm guessing it's just
>> calling the source control's 'status' command in each directory.
>> However, with large directory structures this can take a long time. I
>> sometimes have a non-versioned subtree within the directory structure
>> (created as part of the build) and searching these things is really
>> unnecessary. In my experience with svn and mercurial, just calling the
>> 'st' command in the root directory automatically shows all changes in
>> subdirectories. In theory, meld can just use this list instead of
>> recursively traversing the directory structure looking for changes.
>
> I think some VC plugins do it this way, but not all of them

I'm not surprised. I would suggest then that for VC plugins that do
show all changes recursively that meld take advantage of that. In
other cases, there's not a whole lot one can do except maybe prune
directories that are not under VC.

--
Edwin V
_______________________________________________
meld-list mailing list
meld-list@...
http://mail.gnome.org/mailman/listinfo/meld-list

[Stephen Kennedy]

>>> 1) Why does meld scan from root every time? Should it not just scan
>>> starting from the directory it was invoked from?
>> I've attached a hack which works-for-me. In the meanwhile can you
>> open a bug?
>
> Care to share the hack ?

Here it is - just remember the location passed to set_location
instead of taking the vc root.

Stephen.

git diff HEAD vcview.py (in /home/stephen/dev/meld)
diff --git a/vcview.py b/vcview.py
index 87247f8..369e91c 100644
--- a/vcview.py
+++ b/vcview.py
@@ -245,10 +245,11 @@ class VcView(melddoc.MeldDoc, gnomeglade.Component):
     def on_vc_change(self, cb):
         if not cb.lock:
             self.vc = cb.get_model()[cb.get_active_iter()][1]
-            self._set_location(self.vc.root)
+            self._set_location(self.location)
             self.update_actions_sensitivity()

     def set_location(self, location):
+        self.location = location or "."
         self.choose_vc(vc.get_vcs(os.path.abspath(location or ".")))

     def _set_location(self, location):
_______________________________________________
meld-list mailing list
meld-list@...
http://mail.gnome.org/mailman/listinfo/meld-list