VCS Open API proposed minor changes

1) You might already going on this path but with the current state it is strange that CheckinDialog and CheckinProjectDialog do not derived from the same VCS check in dialog class, like:
CheckinFileDialog extends CheckinDialog
CheckinProjectDialog extends CheckinDialog

Comments, focused component, additional options (missing right now see next point) could be migrated to the base class and shared.

2) CheckinDialog doesn't support additional options (CheckinEnvironmnet.getAdditionalOptionsPanel). Usually if more options/info is provided on project checkin, it would be relevant for file checkin as well. As an example we enter SCR number and pairing info. So it would be easier if both dialog would be extended the same way (see my earlier point).

3) Seems like CheckinProjectdialog uses the Dimension key of the Starteam checkin project dialog.

4) Could we talk about http://www.intellij.net/forums/thread.jsp?forum=23&thread=28445&tstart=0&trange=100 ?

Jacques

14 comments
Comment actions Permalink

Oops forgot one that I am sure you intended to fix anyway:
The 2 accessors CheckinDialog.shouldntBeShown should have a better name (follow bean property convention, not negative, no abbreviation)
isToBeShown/setToBeShown
isShown/setShown
isNeeded/setNeeded
...

It is late and I could not find better names.

Jacques

0
Comment actions Permalink

Thanks, I'll implement this. It's really good ideas.

What's about additional options for CheckinDialog. Did you mean it should be
the same options like in the CheckinProjectDialog? That is not suitable for
cvs. Would it maybe make sense to implement 3 kinds of the additional
options - common, options for single file and for project or directory?

As regards the 4th question.
About external changes I can answer right now. Sinse 877 there is
"markExternalChangesAsUpToDate" method in the AbstractVCS (false by default)
so you can use it to manage upToDate item status after external changes.

--
Best regards,
Olesya Smirnova
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


"Jacques Morel" <jacmorel@yahoo.com> wrote in message
news:28517295.1059556369133.JavaMail.javamailuser@localhost...

Oops forgot one that I am sure you intended to fix anyway:
The 2 accessors CheckinDialog.shouldntBeShown should have a better name

(follow bean property convention, not negative, no abbreviation)

isToBeShown/setToBeShown
isShown/setShown
isNeeded/setNeeded
..

>

It is late and I could not find better names.

>

Jacques

>


0
Comment actions Permalink

Be careful not to confuse what might be suitable for a particular VCS with
what might be useful in principle. Most VCS's differ slightly from the general
interface specified by AbstractVCS, so the best thing is to have a flexible-enough
API and GUI framework.

Olesya Smirnova wrote:

Thanks, I'll implement this. It's really good ideas.

What's about additional options for CheckinDialog. Did you mean it should be
the same options like in the CheckinProjectDialog? That is not suitable for
cvs. Would it maybe make sense to implement 3 kinds of the additional
options - common, options for single file and for project or directory?

As regards the 4th question.
About external changes I can answer right now. Sinse 877 there is
"markExternalChangesAsUpToDate" method in the AbstractVCS (false by default)
so you can use it to manage upToDate item status after external changes.

--
Best regards,
Olesya Smirnova
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


"Jacques Morel" <jacmorel@yahoo.com> wrote in message
news:28517295.1059556369133.JavaMail.javamailuser@localhost...

>>Oops forgot one that I am sure you intended to fix anyway:
>>The 2 accessors CheckinDialog.shouldntBeShown should have a better name


(follow bean property convention, not negative, no abbreviation)

>>isToBeShown/setToBeShown
>>isShown/setShown
>>isNeeded/setNeeded
>>..
>>
>>It is late and I could not find better names.
>>
>>Jacques
>>



--

Erb

==============================================================
"Most of you are familiar with the virtues of a programmer.
There are three, of course: laziness, impatience, and hubris."
- Larry Wall
==============================================================

0
Comment actions Permalink

I completely agree with you Erb.
That is why we have this discussion right now.
Don't you think that with our combined knowledge (mks, p4, clearcase, subversion, vss, bitkeeper/teamware, startteam, cvs) we have a pretty good idea of what should be done?
Let's draft an end vision with the help of the other VCS plugin developers that won't be just for CVS but really opened to 95% of the others.

What do you think Olesya? I am not sure of your priorities. Are you only on cvs2? Obviously from my end it would be nice if you could integrate as you develop cvs2 common VCS api changes.

Jacques

0
Comment actions Permalink

Hi,

I agree with you and Erb I just wanted to say that I would prefer to
implement features which don't contradict cvs integration.

It would be great to combine needs for different version controls. But I
think if I will try to guess all thinkable VCSes the result api will be
cumbersome, confused and absolutely unusable and totally useless.

So I need in your help.
Could you formulate what in the current vcs openapi is inconveniently in use
or absent?

--
Best regards,
Olesya Smirnova
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


"Jacques Morel" <jacmorel@yahoo.com> wrote in message
news:10102805.1060019288273.JavaMail.javamailuser@localhost...

I completely agree with you Erb.
That is why we have this discussion right now.
Don't you think that with our combined knowledge (mks, p4, clearcase,

subversion, vss, bitkeeper/teamware, startteam, cvs) we have a pretty good
idea of what should be done?

Let's draft an end vision with the help of the other VCS plugin developers

that won't be just for CVS but really opened to 95% of the others.
>

What do you think Olesya? I am not sure of your priorities. Are you only

on cvs2? Obviously from my end it would be nice if you could integrate as
you develop cvs2 common VCS api changes.
>

Jacques



0
Comment actions Permalink

Actually I find the current implementation has become quite strong.
For capabilities special to a particular VCS, custom actions can be
added outside the AbstractVCS framework. The big conflict seems to come
where checkout is concerned. I see 3 models use by different VCS's:

1) Do nothing on the server when editing a file; when checking in,
merge if the head revision is changed.

2) Lock a file on checkout, require it to still be locked (and at the same version) when checking in.

3) Mark a file as being edited, but do not prevent others from changing it; merge as necessary.

AbstractVCS remains agnostic as far as this is concerned; The transaction-based model can be used
or ignored.

Some gripes I still have (have filed reports on some):

1) Need that javadoc back! (Some more javadoc comments might be nice, too).
2) Do not by default include the CVS-related menu items (checkout project, edit roots, import).
Either remove them when CVS is not the current VCS, or move them into the VCS core.
Let the user add them (perhaps similar to how mark up-to-date is now enabled), and make sure
they are usable by other VCS's rather than CVS. (All those V's and C's are confusing, huh?)
3) Diff panel needs an open API flag for going to the source line that is clicked on (as in the old
version, and currently in compare/merge).


thanks.

Olesya Smirnova wrote:

Hi,

I agree with you and Erb I just wanted to say that I would prefer to
implement features which don't contradict cvs integration.

It would be great to combine needs for different version controls. But I
think if I will try to guess all thinkable VCSes the result api will be
cumbersome, confused and absolutely unusable and totally useless.

So I need in your help.
Could you formulate what in the current vcs openapi is inconveniently in use
or absent?

--
Best regards,
Olesya Smirnova
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


"Jacques Morel" <jacmorel@yahoo.com> wrote in message
news:10102805.1060019288273.JavaMail.javamailuser@localhost...

>>I completely agree with you Erb.
>>That is why we have this discussion right now.
>>Don't you think that with our combined knowledge (mks, p4, clearcase,


subversion, vss, bitkeeper/teamware, startteam, cvs) we have a pretty good
idea of what should be done?

>>Let's draft an end vision with the help of the other VCS plugin developers


that won't be just for CVS but really opened to 95% of the others.

>>What do you think Olesya? I am not sure of your priorities. Are you only


on cvs2? Obviously from my end it would be nice if you could integrate as
you develop cvs2 common VCS api changes.

>>Jacques



--

Erb

==============================================================
"Most of you are familiar with the virtues of a programmer.
There are three, of course: laziness, impatience, and hubris."
- Larry Wall
==============================================================

0
Comment actions Permalink

Sorry I want to format my answer so I will send it later.

However
*

1) Need that javadoc back! (Some more javadoc comments might be nice, too).

*
Did you know about the openapi_stub.zip in the doc directory? It is a fair replacement. I said fair because it provides more and less
1) More: it includes the source code so in most cases it serves as a documentation because you can reverse-engineer what methods are for. When implementing your own derivatives the implement/override intentions will pick up the parameter names from the source which is nice since I have tons of Mocks (they don't do that with external javadoc see SCR http://www.intellij.net/tracker/idea/viewSCR?publicId=14908 )
2) Less: Since they contain the non-obfuscated source of obfuscated classes, your code will be "red" when it is ok since the editor parser uses the source first and the class after ;-(
In that regard, Olesya, it would be great if you could at least make sure that all classe/method names referenced in openapi classes (whether in or outside the openapi package) are non-obfuscated. Since you provide the source anyway I am not sure what you would loose from this additional exclusion.

*

2) Do not by default include the CVS-related menu items

*
I could not agree more. See the unfornately closed SCR that Erb filed regarding this http://www.intellij.net/tracker/idea/viewSCR?publicId=11683

To Be Continued ;)

Jacques

0
Comment actions Permalink

Yeah, except just about all the OpenAPI classes are abstract classes whose implementation
is in idea.jar (obfuscated). So I could generate JavaDoc from openapi_stub, OK, and I guess that would
be as good as what we had before.

Jacques Morel wrote:

Did you know about the openapi_stub.zip in the doc directory? It is a fair replacement. I said fair because it provides more and less
1) More: it includes the source code so in most cases it serves as a documentation because you can reverse-engineer what methods are for. When implementing your own derivatives the implement/override intentions will pick up the parameter names from the source which is nice since I have tons of Mocks (they don't do that with external javadoc see SCR http://www.intellij.net/tracker/idea/viewSCR?publicId=14908 )
2) Less: Since they contain the non-obfuscated source of obfuscated classes, your code will be "red" when it is ok since the editor parser uses the source first and the class after ;-(
In that regard, Olesya, it would be great if you could at least make sure that all classe/method names referenced in openapi classes (whether in or outside the openapi package) are non-obfuscated. Since you provide the source anyway I am not sure what you would loose from this additional exclusion.


--

Erb

==============================================================
"Most of you are familiar with the virtues of a programmer.
There are three, of course: laziness, impatience, and hubris."
- Larry Wall
==============================================================

0
Comment actions Permalink

Sorry for getting this long to get back to you. I am now back on upgrading the Clearcase plugin.

3 options sounds good to me.
I missed markExternalChangesAsUpToDate completely I am afraid. This is great! However now you need to open up your exclusion mechanism (which is BTW really good!). See http://www.intellij.net/tracker/idea/viewSCR?publicId=15175 for the SCR ;)

While we are talking about check in dialogs, I always thought it was rather smelly to have to create a dialog to see if there was any diffs. Shouldn't the responsibility of knowing if there are differences better handled by a different class then the dialog?
That way it opens the door to our unfinished discussion about access to changes outside of the check in project process and how the checkin project api could be more opened.
Could we finish it in the same thread http://www.intellij.net/forums/thread.jsp?forum=23&thread=28445&tstart=0&trange=100 or when you said "I'll implement this" you were also talking about them too?
I just filed a bug (http://www.intellij.net/tracker/idea/viewSCR?publicId=15174) about the order in which VCS operations are played back which would be obsolete if a VCS plugin was given all changes upfront and not mouth-fed each change.

BTW outstanding job on cvs2. Actually several of us hate you for this. It widens the gap between Clearcase and CVS even more and makes our day job even more miserable ;)

Anyway great talking to you!

Jacques

0
Comment actions Permalink

It seems that I never have enough time to write a longer answer so here is the short list:
1) Getting at and modifying the list of current modifications when using the LVCS as an offline mode.
2) Showing appropriate status for the VCS plugin (changing file status and adding new status like hijacked in ClearCase)

Side question: Are the UserData associated with a VirtualFile saved in the LVCS? If not this would be ideal to cache VCS info with the file (like VCS handles, state) to use w/o connection with server.

This BTW would be great for your CVS integration (Why in CVS do we have to have the server online to do add and delete, I will never understand ) See http://www.intellij.net/tracker/idea/viewSCR?publicId=6720 & http://www.intellij.net/tracker/idea/viewSCR?publicId=12862.

Jacques

0
Comment actions Permalink

There is a status API already.
Ther is a getFileStatusProvider method or something like that is AbstractVCS. Granted, you need
to keep your own record of which file has what status, which relates to your side question.
And you can definitely create your own file statuses.

Jacques Morel wrote:

It seems that I never have enough time to write a longer answer so here is the short list:
1) Getting at and modifying the list of current modifications when using the LVCS as an offline mode.
2) Showing appropriate status for the VCS plugin (changing file status and adding new status like hijacked in ClearCase)

Side question: Are the UserData associated with a VirtualFile saved in the LVCS? If not this would be ideal to cache VCS info with the file (like VCS handles, state) to use w/o connection with server.

This BTW would be great for your CVS integration (Why in CVS do we have to have the server online to do add and delete, I will never understand ) See http://www.intellij.net/tracker/idea/viewSCR?publicId=6720 & http://www.intellij.net/tracker/idea/viewSCR?publicId=12862.

Jacques


--

Erb

==============================================================
"Most of you are familiar with the virtues of a programmer.
There are three, of course: laziness, impatience, and hubris."
- Larry Wall
==============================================================

0
Comment actions Permalink

3) Diff panel needs an open API flag for going to the > source line that is clicked on (as in the old
version, and currently in compare/merge).


As we started to support merge diff panel interface was much reworked. In Arianda openning file in editor was avaliable if diff panel was assigned to a file (it doesn't have any sence more since we allow to compare different files).
Anyway don't worry we open new diff panel interface when find it quite stable.

0
Comment actions Permalink

"I see 3 models use by different VCS's:

1) Do nothing on the server when editing a file; when checking in,
merge if the head revision is changed.

2) Lock a file on checkout, require it to still be locked (and at the same version) when checking in.

3) Mark a file as being edited, but do not prevent others from changing it; merge as necessary."

I guess current implementation allows these models.
If file was checked out as read-only EditFileProvider will be invoked and file will be unlocked or not. Am I wrong?

I am confronted with another difficulties. Commit mechanism implemented in the VcsHelper cannot be applyed to the cvs because of Starteam can perform vcs operation one by one but cvs collect all commiting files and commits them when transaction is commited.
So I should manage progress messages and errors myself.
Are there another vcss using this (transactional) model?

"Getting at and modifying the list of current modifications when using the LVCS as an offline mode."

Use LvcsRevisions to view lvcs modifications. What did you mean by "modifying the list of current modifications"?

"Side question: Are the UserData associated with a VirtualFile saved in the LVCS? If not this would be ideal to cache VCS info with the file (like VCS handles, state) to use w/o connection with server"
User data aren't saved in the local vcs, of course... Could you describe this more in detail?

"This BTW would be great for your CVS integration (Why in CVS do we have to have the server online to do add and delete, I will never understand )"

Me too :) Add and remove commands are implemented using server because of this is implementetion in the javacvs. But we are planning to implement this "completely offline". Unfortunaly to create directory in the cvs we should to connect to the server...

"However now you need to open up your exclusion mechanism"

Well I can create ExcludeProvider and invoke it. CVS will implement it with .cvsignore files.

"While we are talking about check in dialogs, I always thought it was rather smelly to have to create a dialog to see if there was any diffs."

I've been implemented some approach of the FileView and I hope you can use its api to implement FileView for your VCS :)

0
Comment actions Permalink

> If file was checked out as read-only EditFileProvider will be invoked and file will be unlocked or not. Am I wrong?
I always wondered what that one was for ;) I am sure I could use a little bit of javadoc here...

*> I am confronted with other difficulties. Commit mechanism implemented in the VcsHelper

cannot be applied to the cvs because of Starteam can perform vcs operation one by one but
cvs collect all committing files and commits them when transaction is committed.
So I should manage progress messages and errors myself. Are there another vcss using this
(transactional) model?*

BTW Clearcase can be both like CVS or Starteam depending on the mode you are using (UCM or standard)
Even in the case of non-transactional VCS (one by one case), the tight control that the VCS API has is too rigid. Here are the problems I experience:
1) The delete problem mentioned in (http://www.intellij.net/forums/thread.jsp?forum=23&thread=27970 ):
Since there is no visibility from the plugin that a file is being part of a tree that is being deleted, plugin developers have to implement workaround that amounts to hacking. Deleting the top directory is the only thing needed to be done in most modern VCSs .
2) With clearcase for any moveAndCheckin or renameAndCheckin I have to checkout the parent(s), do move/rename, than check back in the parent(s). Imagine when we are doing repackaging and move a bunch of class to other packages. I get 10s of checkout/checkin of the same package. If I would have the list of modification I could do the check in at the end
3) Since LVCS doesn’t track attribute changes (writable) at the end of a check in project I have to do more work (undo checkout of non-modified checked-out files). Since it won’t be part of the normal VcsHelper.doCheckinProject the progress bar won’t reflect true status. In addition the cancel does not work (http://www.intellij.net/tracker/idea/viewSCR?publicId=9488 CRITICAL bug filed on Jan 22 slated for Aurora but not yet fixed ;-).

This is why I believe it would be better to offer a more flexible api: provide access to
a) get modifications,
b) set file status (may be already here like Erb said),
c) use IDEA progress bar.

*>> "Getting at and modifying the list of current modifications when using the LVCS as an offline
>> mode."

Use LvcsRevisions to view lvcs modifications. What did you mean by "modifying the list of
current modifications"?*

To pass to doCheckinProject() right? When I do 1) I need to remove the redundant check in operations.
BTW is there a way in one method call to get all changes since the last Mark Project as Current (kind of analyzeChanges that would return the changes)?
When using the LVCS can I add statuses on top of LVCS? In clearcase for example I can have the following states:
a) checked in (readonly)
b) checked out but not modified
c) checked out modified
d) hijacked (not checked out but writable) but not modified
e) hijacked but modified

LVCS doesn’t track b) and d) and doesn’t make any difference between c) and e). I pretty much know the answer since the lvcs classes do not have any knowledge of VCS statuses.

*>>Side question: Are the UserData associated with a VirtualFile saved in the LVCS? If not this
>>would be ideal to cache VCS info with the file (like VCS handles, state) to use w/o connection
>> with server"

User data aren't saved in the local vcs, of course... Could you describe this more in detail?*

I need to cache some clearcase specific attributes (checked out for example like in 3) ) because clearcase is too slow or I might work offline.

*>>This BTW would be great for your CVS integration (Why in CVS do we have to have the server
>>online to do add and delete, I will never understand )"
>Me too :) Add and remove commands are implemented using server because of this is
>implementation in the javacvs. But we are planning to implement this "completely offline".
>Unfortunately to create directory in the cvs we should to connect to the server...*
Why? Can’t you differ the directory create to commit time using LVCS to cache the operations?

*>>"However now you need to open up your exclusion mechanism"
>Well I can create ExcludeProvider and invoke it. CVS will implement it with .cvsignore files.*
There are 3 aspects to this: the algorithm to exclude files, the gui integration and the persistence. I was talking about all. I implemented an Exclude mechanism already that mark files as uptodate as they change. So I have already the algorithm. Unfortunately the gui is not as integrated as cvs2. It would be nice if plugin developers could benefit from your work as well.
Little side note here. We need to have clear distinction between persistent exclusion (or Ignoring in cvs2) and temporary exclusion (or Excluding in cvs2). It might be too late already but Excluding is stronger then Ignoring so I would intuitively

*>>"While we are talking about check in dialogs, I always thought it was rather smelly to have to
>> create a dialog to see if there was any diffs."
>I've been implemented some approach of the FileView and I hope you can use its api to

implement FileView for your VCS :)*

I am not sure what the FileView is. Its name makes me believe it is purely visual.
I was refering to the fact that it felt wrong that the checkin dialog knew if there were changes or not and was the only API class to know. To me it should just renders them. This responsibility should be better placed elsewhere like the VcsHelper for example since it handles already the project checkin process therefore has access to the changes. As an illustration of that smell, if I do not use the provided checkin dialog I will still have to create one to analyse changes and know if there are any.

Jacques

0

Please sign in to leave a comment.