--
You received this message because you are subscribed to the
"BBEdit Talk" discussion group on Google Groups.
To post to this group, send email to bbe...@googlegroups.com
To unsubscribe from this group, send email to
bbedit+un...@googlegroups.com
For more options, visit this group at
<http://groups.google.com/group/bbedit?hl=en>
If you have a feature request or would like to report a problem,
please email "sup...@barebones.com" rather than posting to the group.
Follow @bbedit on Twitter: <http://www.twitter.com/bbedit>
-Eric
> I've just started working with two other developers on several PHP MVC (model-view-controller) solutions for some of our client's websites and I'm thinking we need to move to some kind of version control system. Does anyone have any advice on what to use? I started looking at Subversion but have to admit I'm rather intimidated by implementing it. Any advise on what to use or where to get started would be appreciated.
>
> -Eric
Subversion is actually a good place to start since it does fairly advanced version control with a minimal learning curve. You can hire subversion hosting to make the server setup and maintenance easier and then use any number of GUI Subversion clients (or the Subversion command built into BBEdit) to interact with the server.
If I were just starting out with version control at this point I would definitely go with git. The learning curve is significantly steeper but the payoff can be inestimable as the one significant feature "lacking" in Subversion is implemented in overdrive in git.
In all fairness, though, there are only 2 times in the past 7 years that I can recall wishing I had been using git, but who knows how much better my code would be had I fully understood git and been able to take advantage of it.
I should also point out that just because you use git doesn't mean you need to use the advanced (complex) features. It works pretty well as a basic VCS too ;-)
My 2¢.
HTH,
Ted Stresen-Reuter
I disagree with the learning curve, I don't think it's any steeper
than other VCSs. It's just that most people start with a
server-centric system like CVS or SVN and then have a harder time
wrapping their heads around a new model (decentralized) of VCS usage.
I've used Git, CVS, SVN, RCS, Perforce, and a number of others over
the years and Git is by far the best one.
My #1 reason to use Git is the fact that the repo is in your local
workspace. Every other system you have to be connected to the network
in order to do simple things like reading the commit logs, diffing
versions, etc. Even if you are forced to use some other centralized
system, you can use git on top of it locally to manage your own
workspace before pushing to the "real" SVN or CVS repo.
If you do any work on the Linux kernel, git is mandatory. It's
becoming so for many more projects also. For example, Drupal is
migrating to git as I type this.
What many people consider git's "advanced" features are actually
fairly natural and are only considered advanced because the same
features are so painful in other VCSs that people avoid them. For
example, branching and merging. Merging branches in CVS is painful.
In SVN (in my experience) it's even worse. In git, it's everyday
practice and easy to do.
Maybe I sound like a Git zealot. I'm not, it just works so much
better for my workflows than other VCS systems. I use SVN extensively
also for various reasons, but even when using SVN for my server, I
usually use git-svn locally.
Many would consider the lack of good graphical tools as a downside.
Perhaps, but a programmer should be comfortable from the commandline.
There's several GUIs for OSX if you're interested:
http://stackoverflow.com/questions/83789/what-is-the-best-git-gui-on-osx
But I just use git from the commandline. BTW, I believe there is a
git integration for BBEdit, done by the Ruby guys.
If you want a decent SVN client for OSX I recommend Cornerstone.
Whatever you choose to use, by all means, use something! No serious
project can be written without a VCS.
- Steve
> What many people consider git's "advanced" features are actually
> fairly natural and are only considered advanced because the same
> features are so painful in other VCSs that people avoid them. For
> example, branching and merging. Merging branches in CVS is painful.
> In SVN (in my experience) it's even worse. In git, it's everyday
> practice and easy to do.
I would add that due to my early exposure to centralized systems, the (easy) concepts in git I find to be particularly hard to get (ha ha), but that's only because I started in a server-based VCS environment.
Steve is right: don't be put off by the (apparent) learning curve. It has been steep for me but I think that's due to my origins, and thus my 20/20 hind-sight choice of git.
Ted
Wrong. Neither CVS nor SVN work that way. The repository can be local or
remote. Locally one can access the repository files directly or
indirectly through a "server" app. Once you have defined the repository
location (and method) for a project that information sticks in the
project. One can freely jump between projects which use different
repositories.
One of the biggest mistakes made in Microsoft environments is to put the
repository on a shared filesystem with multiple users accessing via
direct file methods. With possibly different apps simultaneously
modifying the repository one is asking for trouble, and will get it.
MacOS X comes with SVN preinstalled. Or maybe its in Xcode, don't know
where it comes from. Also comes with ssh. Its a minor hassle to set up
ssh for users but once done svn has no trouble using ssh for remote
access.
Forks are clumsy in SVN, but not all that difficult. You have to arrange
folders for each branch of the fork.
I still use cvs on some projects simply because the project has always
been in cvs and has no pressing reason to change.
--
David Kelly N4HHE, dke...@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.
Double wrong. Or more accurately, misleading.
True: you can use CVS or SVN locally. However, now you can't really
use it with multiple people, removing at least one of the arguments
for using a VCS in the first place (though I recommend using a VCS
even if you're the only one on the project, even if it just for
tracking changes).
Now, if you put the {CVS|SVN} repo on your local machine, hence now
you have local access to it (just like git. well not just like, but
close enough). You can take your laptop with you and you still view
logs, commit, etc. But your coworkers can't use it until you open it
up and server it to them.
So, you can open it up and serve to your coworkers if you like: You
have to give them access via ssh or http or some other relevant
transport, but it's easy enough to do. Now, they take their laptops
to a park to work quietly, and they do an svn log... and they're
screwed because they need network access to your repo. Or worse,
since you work on your laptop, you're on an airplane and five
developers at the office don't have access to the repo.
With SVN or CVS a "server" is required. Period. That "server" may be
on your local machine and may be accessed by direct file-system
methods, but still required. And if that "server" is not accessible,
no reading logs, diffs, or commits for you.
> indirectly through a "server" app. Once you have defined the repository
> location (and method) for a project that information sticks in the
> project. One can freely jump between projects which use different
> repositories.
Yes, true. But repo information is not stored in your local
workspace. A 'svn log' still requires a trip to the real repo. If
you've got that locally on your fs, great. If not, you're
out-of-luck.
>
> One of the biggest mistakes made in Microsoft environments is to put the
> repository on a shared filesystem with multiple users accessing via
> direct file methods. With possibly different apps simultaneously
> modifying the repository one is asking for trouble, and will get it.
>
Same problem is frequent with CVS too. Oh, and also never put the
server on an NFS mount and access it even via the server... eventually
it will corrupt.
- Steve
I really do not figure out how to implement a sorting task which involves items inside a line of text. I know that BBEdit is able to sort lines but what I need is something different.
>
> Try this perl script. You can use it from the command line or you can put it in
> ~/Library/Application Support/BBEdit/Unix Support/Unix Filters/
Here's another way to to it, which will sort alphabetically even if
Bombay is capitalized:
# /usr/bin/perl
use strict; my ($trimmed, @list, %hash);
while (<>) { chomp;
for (split /, */){
$trimmed = $_; $trimmed =~ s~^\d*~~g;
$hash{$trimmed} = $_;
}
for (sort {uc($a) cmp uc($b)} keys %hash){
push @list, $hash{$_};
}
print join ", ", @list;
}
# JD
Looks like I'll take a stab at GIT first.
> My #1 reason to use Git is the fact that the repo is in your local
> workspace.
IMO, this is one of the strongest reasons for using any proper,
sophisticated, modern distributed version control system. Some examples
would be Darcs, Git, Monotone, Mercurial, and Bazaar. I use Monotone, and
I like it a lot, but when it comes to VCS, any of these distributed
systems is going to be preferrable to something like CVS or Subversion,
which still have a distinctly server-centric model, regardless of how well
you can manage offline edits (and yes, you can manage offline editing very
effectively in CVS workflows, but it's a lot of work and the distributed
systems just make it easier for you).
I do think that Git is more complex than the other ones, and I haven't
found it enjoyable to use or fix when things go wrong, but as long as you
are using a distributed version control system, you should have an easy
enough time switching between them when you feel like you're ready to try
something new.
Aaron W. Hsu
--
Programming is just another word for the lost art of thinking.
> I really do not figure out how to implement a sorting task which involves
> items
> inside a line of text.
> I know that BBEdit is able to sort lines but what I need is something
> different.
> The task is quite simple, let's say we have a line of text containing
> comma
> separated items, something like:
>
> *orange, **apple, pear, 1banana, 2apricot, bombay *
>
> and after having selected the whole line I would like to push a
> combination
> of keys
> (something like cmd+O) or select a script and obtain something like:
>
> *apple, 2apricot, 1banana, bombay, orange, pear*
>
> In other words I would like to alphabetically order the comma separated
> items
> inside the line disregarding any optional number that could appear as
> first
> characters
> at the beginning of some items.
>
> Any suggestion will be really appreciated.
I would do this by creating a little script to parse the line for you.
Here's one that I would use in Chez Scheme, but any other programming
language could probably do the job adequately.
#! /usr/bin/env scheme-script
(import (chezscheme) (srfi :13) (srfi :14))
(printf "~{~a~^, ~}~n"
(list-sort
(lambda (a b)
(define (trim s) (string-trim-both s char-set:digit))
(string<? (trim a) (trim b)))
(string-tokenize (get-line (current-input-port))
(char-set-complement
(char-set-union char-set:whitespace
(char-set #\,))))))
Good luck!
THANK YOU!!! both to Matt and the other contributors.
The pearl script works fine and the constrain regarding the number
I only need to know how to assign the Unix Filter to a key combo in
MAC, BBEdit manual doesn't help
for this and the Menu->Preference->... custom keys does not directly
allow for that and redirect to a Unix Folder palette key
assignment...???
#!/usr/bin/perlwhile ( chomp($line = <> )) {@words = split( ', *', $line );map { ( $words{$_} = $_ ) =~ s|^\d*||; } @words;print join( ', ', sort {$words{$a} cmp $words{$b}} keys %words ) . "\n";}__END__