[RFC] Workingstyle of different VCS systems

[Andreas Pakulat]

On 13.04.07 12:55:00, Matthew Woehlke wrote:
> Andras Mantia wrote:
> > On Friday 13 April 2007, Matthew Woehlke wrote:
> >> Why should I not be able to write a script that says 'do this merge,
> >> pop up the UI for anything that needs to be resolved, then commit
> >> it'?
> > 
> > Will you write it? ;) But I see that Andreas wants this as well. My 
> > problem with such a script would be that it needs too much user 
> > interaction and probably it is better to have in the vcs plugins 
> > themselves. You have to select branches, versions, merge, resolve, 
> > commit, well, good luck with the script. :)
> 
> We already worked out how selecting branches would work, versions 
> probably needs user input anyway otherwise it would use globalVersion(), 
> resourceVersion() and log() I think. Andreas, this is a good question, 
> should log() return parsable output for such a script?

I'm not sure. That depends on what information the VCS systems can
present here. As far as SVN is concerned you see the commit message,
revision information, comitter, commit date and difference in number of
files. I don't have CVS around, but I guess its pretty much the same,
except maybe for the #lines.

> >> I think one objective of having a defined interface is to provide the
> >> GUI as part of the interface, so that you don't *need* to
> >> re-implement the GUI for every back-end.
> > 
> > Interfaces (in this case) are just like that...interfaces. GUIs are 
> > provided by implementation (or as I said by another library). I would 
> > like to see this separation kept.
> 
> Yes, we agreed there, but the interface is so the GUI can get the data 
> it needs, and/or so a generic client can trigger the action consistently.

No, I don't think the GUI will use the interface to get data. Currently
my vision is to just provide widgets that the plugins will use. I still
think we should have properly defined interfaces for all actions that
are common among the VCSes so if something (whatever that is) gets a
IVCS or IBranchableVCS it instantly knows what it can do with this
plugin. Else other code has to link to each plugin to get to know its
actions. And I think we shouldn't limit the list of methods except for
stuff that is not common. 

> >> - Allow scripts to use VCS methods
> > And this is where I suggest to identify the methods that really make 
> > sense to be used from scripts.
> 
> for Vic's project, we also want a GUI front-end to be able to call e.g. 
> diff() on an arbitrary plug-in. We seem to have raised the question of 
> whether diff(), log(), etc should be functions (return parsable output) 
> or actions (pop up a UI).

Well, what format do we use for diff? unified diff? Does that work for
all VCSes? As for log I think we need both. The action in the action
collection should trigger a UI popup, while it may make sense to have a
log() function that returns a struct with comment,committer,date and
revision.

> >> ...and this is why log(), globalVersion(), diff(), etc are all things
> >> we want in the interface. That way we have *one* GUI using the
> >> standardized interface instead of every single back-end reinventing
> >> the wheel when it comes to UI's that are common to most/all VCS's.
> >>
> >> Code reuse = good.
> > 
> > I'm far from being against code reuse. I'm just on the other side now 
> > (compared to the activeProject or activeMainWindow discussion), where I 
> > want to have the interfaces as simple as possible by not adding methods 
> > that will never be used.
> 
> Ok, I can concede that. Unfortunately it is hard to add things later, 
> because if we don't add them now, they become optional interfaces and 
> you have to check for them to use them. It also means back-ends may be 
> slow to adopt the optional interfaces if we create them later.

No, its easy to add things later. We create a new version of the
Interface and all plugins that want to support the new methods need to
implement the new interface. They are also encouraged to implement the
old interface so that old code that uses the old interface still can use
the plugin.

> >>>> We never really talked about this, but I don't think there should
> >>>> be an interface for "special". Individual back-ends can provide
> >>>> (outside the defined common interfaces) anything they feel useful.
> >>> And how would you access them?
> >> The same way you want plugins to provide diff, etc; the back-end adds
> >> any additional actions not defined by one of the interfaces it
> >> implements. They are only scriptable if you write the script for that
> >> specific back-end, and only if said back-end provides them in a
> >> script-friendly form. Which is OK.
> 
> First, keep in mind that this might be hard to implement if we are using 
> the C (or C++, or Qt, or...) libraries for svn because we otherwise 
> won't be calling a command line client at all.

I think I don't understand. Why does the implementation of the svn
plugin imposes problems for scripts using the plugin via the interface
we define?

> Second, since this is 
> only usable if a plug-in or script knows what back-end it is using, then 
> I don't see the problem calling non-standard interfaces directly. And of 
> course, third, a back-end that wants can always choose to implement 
> command().

No, no code whatsoever should ever care about which plugin it gets. All
the code is allowed to care about is what interface that plugin has that
it wants to use.

So if a svn plugin wants to add cleanup() for scripts to use, it needs
to define a ISVNSCM interface that provides this.

Andreas

-- 
Your supervisor is thinking about you.