direct repository browsing.

I would like to suggest "direct repository
browsing"
as a new pysvn workbench feature.

We have some Windows users here at ICEM, who still use
TortoiseSVN instead of pysvn workbench.
"direct repository browsing" would be among the
features
they think they need before they want to switch.

I talked to one of them today and found out that his
highlights of TortoiseSVN's "direct repository
browsing"
are:

*  tree/explorer view of the entire repository.
   I think this is similar to pysvn workbench's tree
   view on the left side of the main window.

*  Option to view the log history of any file/directory.

*  Option to view a diff between any two files.

I guess that an acceptable way of implementing this,
would be a project entry that has a URL, but no
working copy.
Most of pysvn workbench's current functions could be
made available onae after another for such a project entry,
the rest of them would have to be greyed out in the menus.


What do you think?

Carsten.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribepysvn.tigris.org
For additional commands, e-mail: dev-helppysvn.tigris.org

On Sep 29, 2006, at 15:41, Carsten Koch wrote:

> I would like to suggest "direct repository
browsing"
> as a new pysvn workbench feature.
>
> We have some Windows users here at ICEM, who still use
> TortoiseSVN instead of pysvn workbench.
> "direct repository browsing" would be among
the features
> they think they need before they want to switch.
>
> I talked to one of them today and found out that his
> highlights of TortoiseSVN's "direct repository
browsing"
> are:
>
> *  tree/explorer view of the entire repository.
>    I think this is similar to pysvn workbench's tree
>    view on the left side of the main window.


> *  Option to view the log history of any
file/directory.
>
> *  Option to view a diff between any two files.
>
> I guess that an acceptable way of implementing this,
> would be a project entry that has a URL, but no
> working copy.
>

Agreed.

> Most of pysvn workbench's current functions could be
> made available onae after another for such a project
entry,
> the rest of them would have to be greyed out in the
menus.
>

The context menu would just have the actions that apply to a
URL.
The action menu would have to grey out as you suggest.

>
> What do you think?

I have no objections. Its only a lack of time problem.

With svn 1.4.0 the list() is available that is the API bug
fixed ls().
Making this a svn 1.4.0 feature may well make life easier.

Barry

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribepysvn.tigris.org
For additional commands, e-mail: dev-helppysvn.tigris.org

On Sep 29, 2006, at 20:23, Barry Scott wrote:

>
> I have no objections. Its only a lack of time problem.
>
> With svn 1.4.0 the list() is available that is the API
bug fixed ls().
> Making this a svn 1.4.0 feature may well make life
easier.
>

There is a architecture problem/assumption in WorkBench that
we will
have to design a solution to.

At the moment the UI freezes until the status() function
returns  
results.
This is ok because almost all the time the results take less
then a  
second
to collect.

But the list() can take a very long time. We cannot have the
UI frozen
while this is happening.

The list() will have to return data asynchronously and the
display  
will update
when its returned. This is nothing like the way the existing
tree or  
list works.

Barry

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribepysvn.tigris.org
For additional commands, e-mail: dev-helppysvn.tigris.org

Greetings

  I agree that prevention is better than cure and once
infected better to
blat and start again, that being said, it would be good to
be able to
prevent malcious execution, possibly through command
feedback (at least you
can see if anything got run in teh backround).

  Limiting it too one iteration could possibly break some of
it uses in
extended comand line arguments or scripts eg :
"sudo find /restricted_path/ | xargs sudo rm"

  A wrapper script could also be used but that is a little
dirty.


  Any ideas?


-- 
_______________________________________
( R e g a r d s                         )
(                                       )
( M i c h a e l  L  G r i f f i n       )
( michaelgriffin.org.za                )
( http://www.griffin.org.za             )
( Fax : +27 86 670 8945                 )
( Cel : +27 83 462 0462                 )
(                                       )
( Next step in OS evolution is found on )
( the command line...                   )
(                       .: L I N U X :. )
---------------------------------------
   o
    o
        .--.
       |o_o |
       |:_/ |
      //    
     (|     | )
    /'_   _/`
    ___)=(___/
Confucius: He who play in root,
           eventually kill tree.



On 11/01/07, Bob Proulx <bobproulx.com> wrote:
>
> David wrote:
> > Question: In a distro where sudo is enabled by
default (eg Ubuntu),
> > how are privilege escalations via sudo avoided?
>
> The same as when sudo is not enabled.
>
> > 2) Bob's user account gets compromised (eg, he
views an image that
> > exploits a buffer overrun in libpng)
>
> Bob's box is now completely suspect either with or
without sudo.  Take
> the disk offline and image it for forensic analysis of
how the exploit
> occurred.  Wipe the disk clean and install fresh from
known good
> sources.  Take corrective action to avoid the previous
exploit.
>
> Bob
>
> --
> But I don't even know Alice.  
>
____________________________________________________________

> sudo-users mailing list <sudo-userssudo.ws>
> For list information, options, or to unsubscribe,
visit:
> http:/
/www.sudo.ws/mailman/listinfo/sudo-users
>
____________________________________________________________

sudo-users mailing list <sudo-userssudo.ws>
For list information, options, or to unsubscribe, visit:
http:/
/www.sudo.ws/mailman/listinfo/sudo-users

Barry Scott wrote:
> 
> On Sep 29, 2006, at 20:23, Barry Scott wrote:
> 
>>
>> I have no objections. Its only a lack of time
problem.
>>
>> With svn 1.4.0 the list() is available that is the
API bug fixed ls().
>> Making this a svn 1.4.0 feature may well make life
easier.
>>
> 
> There is a architecture problem/assumption in WorkBench
that we will
> have to design a solution to.
> 
> At the moment the UI freezes until the status()
function returns results.
> This is ok because almost all the time the results take
less then a second
> to collect.
> 
> But the list() can take a very long time. We cannot
have the UI frozen
> while this is happening.
> 
> The list() will have to return data asynchronously and
the display will
> update
> when its returned. This is nothing like the way the
existing tree or
> list works.

I discussed this again yesterday with the
Windows/Tortoisesvn users
who do not want to switch to workbench before it has direct
repository browsing.
They mentioned that in Tortoisesvn the list update is not
automatic.
It is explicitly triggered by a button.
Somewhat similar to the "Report" functions in
workbench, I guess.

Would that solve the problem?

Carsten.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribepysvn.tigris.org
For additional commands, e-mail: dev-helppysvn.tigris.org

On Jan 25, 2007, at 17:03, Carsten Koch wrote:

> Barry Scott wrote:
>>
>> On Sep 29, 2006, at 20:23, Barry Scott wrote:
>>
>>>
>>> I have no objections. Its only a lack of time
problem.
>>>
>>> With svn 1.4.0 the list() is available that is
the API bug fixed  
>>> ls().
>>> Making this a svn 1.4.0 feature may well make
life easier.
>>>
>>
>> There is a architecture problem/assumption in
WorkBench that we will
>> have to design a solution to.
>>
>> At the moment the UI freezes until the status()
function returns  
>> results.
>> This is ok because almost all the time the results
take less then  
>> a second
>> to collect.
>>
>> But the list() can take a very long time. We cannot
have the UI  
>> frozen
>> while this is happening.
>>
>> The list() will have to return data asynchronously
and the display  
>> will
>> update
>> when its returned. This is nothing like the way the
existing tree or
>> list works.
>
> I discussed this again yesterday with the
Windows/Tortoisesvn users
> who do not want to switch to workbench before it has
direct  
> repository browsing.
> They mentioned that in Tortoisesvn the list update is
not automatic.
> It is explicitly triggered by a button.
> Somewhat similar to the "Report" functions in
workbench, I guess.
>
> Would that solve the problem?

If you can only see one folder at time maybe it does.

But what I'd like is repo browsing to work the same way as
the
wc browsing.

At some point I'll figure out how to do this in workbench.
I'm
turning over ideas slowing as a background problem.
Once we have the usage worked out I just need a few days
free to prototype the code.

Barry



------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribepysvn.tigris.org
For additional commands, e-mail: dev-helppysvn.tigris.org