Author Topic: Could slickedit support GIT - the fast version control system?  (Read 5602 times)

zhangxudong

  • Community Member
  • Posts: 18
  • Hero Points: 0
I use GIT manage my source now, could SlickEdit support GIT in SE 2009?

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Re: Could slickedit support GIT - the fast version control system?
« Reply #1 on: March 22, 2009, 04:36:31 AM »
We have no plans to add formal support for GIT at this time. You can add support for any package that uses command lines by selecting Tools > Version Control > Setup . Put a check in "Command line systems", then click the "Add" button. Type in the name, like "GIT", and click OK.

You will be placed in the Options hierarchy on the new "GIT" node. Click on the "Commands" subnode and define the command that is used for each of the operations listed, or at least for the ones you use.

If someone could send us the set of commands to use, we would be happy to include that in a future version for other customers to share. We still have to plan what will be done during our normal Summer update, so we may be able to include those then. It's far more likely if we can get some help from the user community.

Bhelyer

  • Community Member
  • Posts: 29
  • Hero Points: 3
Re: Could slickedit support GIT - the fast version control system?
« Reply #2 on: March 22, 2009, 10:08:26 AM »
Yeah, I would love git support.

I find the command descriptions confusing as all paved with good intentions (that censor is hilarious, so I think I'll leave it). I have tried several times, but I can't figure out what you mean with specific commands. I don't trust myself not to screw something up awfully. If someone smarter than I could do it, that would be great.
« Last Edit: March 22, 2009, 10:10:09 AM by Bhelyer »

jbhurst

  • Senior Community Member
  • Posts: 406
  • Hero Points: 33
Re: Could slickedit support GIT - the fast version control system?
« Reply #3 on: March 22, 2009, 07:11:35 PM »
FWIW, the version control systems I use nowadays are Subversion and git. Any git support would be welcome.

For that matter, any improvements to version control support in general would be most welcome. The SlickEdit version control support is rather dated and doesn't seem to get a lot of attention. You would think that it would be a central feature of the product, being relevant to *all* users.

I'll try to dig out some comments I made about this a couple of years ago.

John Hurst
Wellington, New Zealand

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Re: Could slickedit support GIT - the fast version control system?
« Reply #4 on: March 22, 2009, 07:23:29 PM »
We agree that version control support is important, but it is hard to provide a universal solution. No one tool holds enough of the market to spend a great deal of time building custom interfaces. So, we have coded a general interface to allow folks to customize SlickEdit to work with their particular tool.

Please post any suggestions you have for improvements. I'd be very interested in seeing what we can do.

Bhelyer

  • Community Member
  • Posts: 29
  • Hero Points: 3
Re: Could slickedit support GIT - the fast version control system?
« Reply #5 on: March 26, 2009, 02:35:47 AM »
Alright. I want to get git working with the command line setup tools. Like I said before, the (SE editable list of) commands as listed are confusing and undocumented, so I'm going to ask for clarification on those I don't understand, and give my best guess on others. I haven't tested any of this yet, I will in the future.




Add
What does SE want this command to do? I would assume it refers to adding new files that are currently not in the repository, so I guess the command would be:

Code: [Select]
git add %f
Perhaps it assumes that a commit isn't necessary? So maybe

Code: [Select]
git add %f; git commit -m "Added %f"



Checkin
To what? The remote repository? That isn't guaranteed to exist with a DVCS, so using

Code: [Select]
git push

Would be silly. Assuming that people will deal with pushing to remote repos on their own, perhaps

Code: [Select]
git commit -a -m "%c"

would be the best. Is %c what I think it is? Are quotation marks needed? Maybe it wants to work on individual files?

Code: [Select]
git add %f; git commit -m %c



Checkout
Again, we cannot assume that assume that we are working from a remote repository. If we were,

Code: [Select]
git pull

Would go here. Does this want to operate on single files? If so, I don't know if that is possible.




Difference
Difference between what? A file's current state, compared to the state of the HEAD? The entire repository compared to the HEAD? Beats me. In the first case,

Code: [Select]
git diff %f

Would work if %f's changes haven't been commited. Does SE expect a certain kind of output (unified diff), or does it just print the output out?




Get
Get what? How does this differ from Checkout?




History
Of the whole repository? Of a single file? In the former case,

Code: [Select]
git log

Would go here. In the latter,

Code: [Select]
git log %f

Would be the ticket.




Lock
AFAIK, Git has no support of locking, so this can't be implemented here.




Manager
What?




Properties
Of what? A file? Revision? No idea, personally.




Remove
Is this supposed to be 'remove a file from the filesystem, and from the repository.'?
Code: [Select]
rm %f; git rm %f; git commit -m "Removed %f"

or

'remove a file from the repository, but keep it on the filesystem'
Code: [Select]
git rm %f; git commit -m "Removed %f"

And what about those commit messages? Will %c give a commit message regarding removal? Will %f even expand like I hope it does?




Unlock
Again, locking not supported, so unlocking does nothing too.



Now, if people (SE devs, smart people, whoever) could correct my mistakes, assumptions, and fill in the blanks - that would be wonderful. I will play around with a toy repository at some point.





« Last Edit: March 26, 2009, 02:45:48 AM by Bhelyer »

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 128
Re: Could slickedit support GIT - the fast version control system?
« Reply #6 on: March 26, 2009, 04:35:00 AM »
GIT sounds like it strays quite a bit from typical source control manager (I'll use the typical abbreviation "SCM" here) behavior, so it may need some glue.  You can provide the glue via scripts.  If GIT is the only system one has experienced, then I can imagine it would be confusing how to map its behavior into the typical SCM actions.

Some of your questions are answered in SlickEdit's Help system topic on its Version Control support:

Quote
Overview of Version Control
Version control is accessed from the Tools → Version Control menu, by right-clicking within a file or buffer, or by right-clicking on an item in the Files list of the Open tool window.

The History, Difference, Lock, and Properties commands operate on the current buffer. For SCC version control systems, the SCC provider's function is called. For command line version control systems, the specified command is run, and the output is displayed.

The Check In, Get, Check Out, Unlock, Add, and Remove commands show a dialog box and operate on all files selected. This dialog will allow you to easily choose from files currently open, the files in the current project, or files in the current workspace. Note that CVS operations are different and designed to work especially well with CVS. Also, for SCC version control systems, you can select from files that are valid for that command. For example, when using the Check In command, you can click Available to view all files that can currently be checked in.

Use the Manager command to bring up the version control system's user interface. For many command line systems there will not be a program to call for this.

Menu items that appear grayed out for a command line version control system are blank. For SCC version control systems, Lock is always unavailable because the SCC interface does not make allowances for a lock command. It is possible to receive an Operation not supported message when running some commands if an SCC version control system does not implement an interface to that operation.



Some more specific answers follow below.  But you invoke these commands -- so you can choose what you want them to do.  The only one that SE invokes automatically on your behalf is "Checkout", the rest are invoked by you.  For example, if you want "History" to launch your favorite game, you can make it do that.


Add
What does SE want this command to do? I would assume it refers to adding new files that are currently not in the repository,
Yes.  Use this to add a file to the SCM.  It sounds like GIT has two modes -- local repository, or remote repository.  Probably pick which way you want the Add command to work.  You can always write a custom macro for the other flavor.

Checkin
Use this to record your changes in the SCM.  If there are multiple commands for different contexts, write a script that figures out the context and then invokes the appropriate command.

Checkout
Again, we cannot assume that assume that we are working from a remote repository.
Use this to let the SCM know that you want to edit the file.  If there are multiple commands for different contexts, write a script to disambiguate and invoke an appropriate command.

Difference
Difference between what? A file's current state, compared to the state of the HEAD? The entire repository compared to the HEAD? Beats me.
Use this to see the edits you've made to the file, i.e. compared to the state of the file before you told the SCM that you wanted to edit the file.  Or at least that's typically what people want a diff command to do in an SCM.  If you want it to do something different, fill in whatever command you want it to do.

Get
Get what? How does this differ from Checkout?
Use this to get the head revision from the SCM.

History
Of the whole repository? Of a single file? In the former case,
Use this to view the history of the file being edited.

Lock
AFAIK, Git has no support of locking, so this can't be implemented here.
Apparently for GIT, leave it blank.

Manager
What?
Use this to launch a GUI program for viewing the repository.

Properties
Of what? A file? Revision? No idea, personally.
Use this to view/edit SCM properties of the file being edited.  Or whatever kind of properties you feel are appropriate to view in the context of SCM.  Or leave it blank.

Remove
Is this supposed to be 'remove a file from the filesystem, and from the repository.'?
Use this to tell the SCM that you want to remove the file from the SCM.  Or whatever "remove" means to you.  If there are multiple actions that differ by context, write a script to infer context and invoke an appropriate command.

Unlock
Again, locking not supported, so unlocking does nothing too.
Apparently for GIT, leave it blank.


Hope that helps.

SlickEdit's Help could be a little more verbose about the SCM stuff, but in all fairness it sounds like GIT is an atypical SCM.  SlickEdit's commands mirror the standard SCM actions -- even if some SCMs use different terms, the similarities between most SCMs make it pretty clear how SlickEdit assumes the user will want to use the commands.

Bhelyer

  • Community Member
  • Posts: 29
  • Hero Points: 3
Re: Could slickedit support GIT - the fast version control system?
« Reply #7 on: March 26, 2009, 07:10:52 AM »
GIT sounds like it strays quite a bit from typical source control manager (I'll use the typical abbreviation "SCM" here) behavior, so it may need some glue.  You can provide the glue via scripts.  If GIT is the only system one has experienced, then I can imagine it would be confusing how to map its behavior into the typical SCM actions.

Some of your questions are answered in SlickEdit's Help system topic on its Version Control support:

Quote
Overview of Version Control
Version control is accessed from the Tools → Version Control menu, by right-clicking within a file or buffer, or by right-clicking on an item in the Files list of the Open tool window.

The History, Difference, Lock, and Properties commands operate on the current buffer. For SCC version control systems, the SCC provider's function is called. For command line version control systems, the specified command is run, and the output is displayed.

The Check In, Get, Check Out, Unlock, Add, and Remove commands show a dialog box and operate on all files selected. This dialog will allow you to easily choose from files currently open, the files in the current project, or files in the current workspace. Note that CVS operations are different and designed to work especially well with CVS. Also, for SCC version control systems, you can select from files that are valid for that command. For example, when using the Check In command, you can click Available to view all files that can currently be checked in.

Use the Manager command to bring up the version control system's user interface. For many command line systems there will not be a program to call for this.

Menu items that appear grayed out for a command line version control system are blank. For SCC version control systems, Lock is always unavailable because the SCC interface does not make allowances for a lock command. It is possible to receive an Operation not supported message when running some commands if an SCC version control system does not implement an interface to that operation.

Why doesn't that show up when I click 'help' in the SCM options dialogue? Sorry guys, I guess SE is better documented than I thought. :3

Thank you for your in-depth explanation. I shall go through and try and get this all working. :')

EDIT:

After a bit of prodding, I have basic support for git added. 'Clunky' is an understatement at this point. One oddity: When you add a new file, you can't add it when it asks you, as the file isn't saved until you, err, save it (not when it asks you), so git add %f does nothing, and the commit doesn't go through (as it is empty). This can be worked around by always saying no, saving your new file, then adding it.

Quote
Yes.  Use this to add a file to the SCM.  It sounds like GIT has two modes -- local repository, or remote repository.

The repository is always local, hence the 'distributed' in 'distributed version control'. But it is sometimes used in a more centralized fashion (like SVN) with a central repository getting pushed to (with the commits from your still local repository). But, like I say, that can be handled by hand, so I'm just going to operate on the local repository with this first pass on the commands.
« Last Edit: March 26, 2009, 09:00:37 AM by Bhelyer »

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Re: Could slickedit support GIT - the fast version control system?
« Reply #8 on: March 26, 2009, 03:06:00 PM »
Not much more to add to chrisant's detiled descriptions.  These commands are whatever they mean to you and what makes sense in your workflow. Most version control systems have an analog that can be mapped to each of the commands, but you may find that you don't need all of the commands.

For example, you may not need both checkout and get. Most systems distinguish between a fetch with a lock and a fetch without a lock. SourceSafe is one such system. In that system, a checkout gets the latest version of the file and locks it so that no one else can checkin. A get is used to just fetch the latest version and does not establish a lock. Some systems are have very specific use patterns regarding locking and others leave it up to you as to how you want to work.

So, define these commands in a way that makes sense to you and how you work.

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 128
Re: Could slickedit support GIT - the fast version control system?
« Reply #9 on: March 26, 2009, 07:34:44 PM »
Why doesn't that show up when I click 'help' in the SCM options dialogue? Sorry guys, I guess SE is better documented than I thought. :3
I think it is, but you have to scroll up to get to the part I quoted.
In general, the SlickEdit help is written as long sections, and "topics" are more like "hyperlinks to a particular line in the section about related stuff".  So typically scrolling up or down reveals other related stuff.