Adrian, I'd love to hear more about your workflow. Could you give an
example of how you use this set-up for things like branching and
merging?
Cheers,
Greg
···
On 21 mar, 10:49, Adrian Howard <adri...@quietstars.com> wrote:
You might want to consider using SVK as your client (if you're happy
using the command line). It's a distributed system built on top of
subversion - so you can mirror subversion repos locally and push/pull
changes between your local copy and the main one.
I've been using it for about a year as my primary way of talking to
subversion and have been very happy with it.
With all of this talk about SVN vs. anything not CVS, I would love to
see some ideas of how one could apply an svn interface to an existing
distributed tool. Some get close but maybe someone should make a
centralized "porcelain" for git? I don't see any reason you couldn't
implement a good portion of behaviors people seem to like.
Porcelain? I was expecting to find a SVN UI with the google I just did.
Assuming $R is my "master" subversion repository I do something like this
1) At the start of a project set up a mirror...
svk mirror $R/project/foo/trunk //foo/trunk
2) ... and a local branch
svk cp //foo/trunk //foo/local -m 'a local branch for local folk'
3) Check out a working copy into the foo directory
svk co //foo/local foo
4) Pull changes down from the central server
svk pull foo
I can then merrily work away in my local foo working copy committing to my local branch on my local machine. When I want to push my changes back to the central server I do
svk push --verbatim foo
(The --verbatim bit reproduces the commits you made to the local repo on the remote one, rather than merging them into one big commit. Makes it easier to track changes)
That's basically it.
Cheers,
Adrian
···
On 21 Mar 2007, at 15:30, Greg Hurrell wrote:
On 21 mar, 10:49, Adrian Howard <adri...@quietstars.com> wrote:
You might want to consider using SVK as your client (if you're happy
using the command line). It's a distributed system built on top of
subversion - so you can mirror subversion repos locally and push/pull
changes between your local copy and the main one.
I've been using it for about a year as my primary way of talking to
subversion and have been very happy with it.
Adrian, I'd love to hear more about your workflow. Could you give an
example of how you use this set-up for things like branching and
merging?
I'm just catching up on some old email (so my comment may be far off the mark
(or out of date)), but you (anybody might want to look into svk (try
googling for it).
I haven't tried it, but it was recommended to me as sort of a front end that
would let me:
* use svn type commands
* maintain a local and remote repository (i.e., distributed)
* and the remote repository could be a variety of things, including CVS,
SVN, Darcs, and ...?
Randy Kramer
···
On Monday 12 March 2007 10:51 pm, Brian Mitchell wrote:
I think you hit it in just one direction. The real value I find in
cherry picking is when I am providing a set of patches to an upstream
developer who may or may not want to merge certain things at any one
time. Most distributed systems handle this quite well though I think
darcs wins when it comes to the user effort needed. Other systems
often rely on complicated patch maintenance systems or force constant
"rebasing" patches with each revision (better than no support though).
The end result seems to be that you can avoid playing the baby sitter
between branches all the time. No more merge chores just to keep
things up to date. Of course, that isn't to say that avoiding merge
work always works either.
With all of this talk about SVN vs. anything not CVS, I would love to
see some ideas of how one could apply an svn interface to an existing
distributed tool. Some get close but maybe someone should make a
centralized "porcelain" for git? I don't see any reason you couldn't
implement a good portion of behaviors people seem to like.
"Besides providing a version control system, the Git project provides
a generic low-level toolkit for tree history storage and directory
content management. Traditionally, the toolkit is called the plumbing.
Several other projects (so-called porcelains) offer compatible version
control interfaces - see the related tools list."
I guess that is the mentality you get from a linux kernel hacker. It's
all plumbing or it must be porcelain.
Brian.
···
On 3/13/07, benjohn@fysh.org <benjohn@fysh.org> wrote:
> With all of this talk about SVN vs. anything not CVS, I would love to
> see some ideas of how one could apply an svn interface to an existing
> distributed tool. Some get close but maybe someone should make a
> centralized "porcelain" for git? I don't see any reason you couldn't
> implement a good portion of behaviors people seem to like.
Porcelain? I was expecting to find a SVN UI with the google I just did.
To comment on the original question, SVN has the following going for it:
* free
* cross-platform
* commercial support
* large installations
* vast community knowledge
* editor/ide/tool integration
* visual UI options
* good administrative tools/practices
* fair security/authentication tools
* written in a common and performant language
* stable
I've used VSS, ClearCase, Perforce(currently at work), CVS, SVN, Darcs,
SVK, and some others I can't remember. Perforce is very good, but
expensive. SVK - i do use it but I can't seem to get past my bias
against Perl. I couldn't even begin to look at Git because I use Windows
and Mac mostly. Darcs is performant, free, and cross-platform - all good
- but it doesn't compete against the list above, at least not yet. I'm
keeping my eye on it, though. I wouldn't use VSS, CVS, or ClearCase
again, given the choice.
I think this list is why SVN is such an easy choice. None of these are
perfect, so it comes down to your work style and project needs.
Distributed systems make more sense for start-ups with all remote devs
than in big brick-and-mortar enterprises with all on-site development.
Perforce would be hard to beat if it were free and had a distributed
option, but I don't see the free thing happening any time soon. Find
wide adoption and support of Darcs, or decentralization of Subversion,
and you may find a break-away leader. Until then you need to ask "which
one fits the way I/we work?".
As Ryan said, this isn't completely true for open source projects
(although it seems a little harder for a non-GPLed project; I haven't
tried to set one up, yet). However, even for corporations, Perforce
isn't *that* expensive compared to some of its competition and how
much it provides, and the level of support is just amazing.
It's not going to be something that start-ups use first, though. If I
were to use Perforce myself, though, I'd set up a public read-only SVN
repository for others to access.
-austin
···
On 4/2/07, Kevin Williams <kevwil@gmail.com> wrote:
You did not mention mercurial which is easier to start with than
darcs. It uses python which is more widespread than the thing darcs
uses.
Unlike git I haven't seen a large project using mercurial (yet).
However, I guess pretty much all the advantages you named above would
apply to mercurial as well.
There is a link to SCM comparison site earlier in the thread. From
that it looks like the centralized SCMs are more space efficient in
some cases (ie working on part of the repository) at the cost of being
less flexible (only one central repository to which you need access
all the time, harder branching).
To me the move the use of distributed SCM brings complete new way of
thinking about code management that things like SVK do not. All the
repositories are the same, one may be "central" only because more
people use it than any other.
Thanks
Michal
···
On 4/3/07, Kevin Williams <kevwil@gmail.com> wrote:
To comment on the original question, SVN has the following going for it:
* free
* cross-platform
* commercial support
* large installations
* vast community knowledge
* editor/ide/tool integration
* visual UI options
* good administrative tools/practices
* fair security/authentication tools
* written in a common and performant language
* stable
I've used VSS, ClearCase, Perforce(currently at work), CVS, SVN, Darcs,
SVK, and some others I can't remember. Perforce is very good, but
expensive. SVK - i do use it but I can't seem to get past my bias
against Perl. I couldn't even begin to look at Git because I use Windows
and Mac mostly. Darcs is performant, free, and cross-platform - all good
- but it doesn't compete against the list above, at least not yet. I'm
keeping my eye on it, though. I wouldn't use VSS, CVS, or ClearCase
again, given the choice.
I think this list is why SVN is such an easy choice. None of these are
perfect, so it comes down to your work style and project needs.
Distributed systems make more sense for start-ups with all remote devs
than in big brick-and-mortar enterprises with all on-site development.
Perforce would be hard to beat if it were free and had a distributed
option, but I don't see the free thing happening any time soon. Find
wide adoption and support of Darcs, or decentralization of Subversion,
and you may find a break-away leader. Until then you need to ask "which
one fits the way I/we work?".
You did not mention mercurial which is easier to start with than
darcs. It uses python which is more widespread than the thing darcs
uses.
Unlike git I haven't seen a large project using mercurial (yet).
Mercurial was choosed by OpenSolaris, but I don't know if it's already used or not.
Not entirely true. To be clear: Perforce licenses are FREE for open
source projects.
But having to renew the licenses every year is a PITA. (been there, done
that for 5 years and saw the process getting more complicated over the
years).
In the end, I switched over to Arch when they asked me to *fax* both the
GPL and BSD license to them to get my renewed license... Nuff said.
I've switched to Mercurial and won't come back ever to centralised
systems like svn.
That is hard to do actually. At least, I haven't found any scripts that do a good job of it (esp with continual/periodic updates). I'm finishing up the last of the edge cases on my script to do just that and will be releasing it "soon". I think all I have left is to delete empty dirs in svn (which at this point I may just do by hand because it isn't THAT big of a deal).
If you know of any good scripts for this, I'd love to look at them.
···
On Apr 3, 2007, at 05:13 , Austin Ziegler wrote:
It's not going to be something that start-ups use first, though. If I
were to use Perforce myself, though, I'd set up a public read-only SVN
repository for others to access.
On 4/2/07, Kevin Williams <kevwil@gmail.com> wrote:
Perforce is very good, but expensive.
As Ryan said, this isn't completely true for open source projects
(although it seems a little harder for a non-GPLed project; I haven't
tried to set one up, yet). However, even for corporations, Perforce
isn't *that* expensive compared to some of its competition and how
much it provides, and the level of support is just amazing.
It's not going to be something that start-ups use first, though. If I
were to use Perforce myself, though, I'd set up a public read-only SVN
repository for others to access.
I saw an interesting article about bazaar, which is meant to be a replacement
for subversion that is designed specifically for open source type projects
which have many different contributors/developers and is supposed to be easier
and more intuitive than subversion. It sounded interesting.
Not entirely true. To be clear: Perforce licenses are FREE for open
source projects.
But having to renew the licenses every year is a PITA.
It isn't _that_ much of a PITA for the benefits of using perforce for free.
(been there, done
that for 5 years and saw the process getting more complicated over the
years).
No, it is getting easier.
I've been running my perforce server for about 8 years running now and while for a while they were indeed requiring a FAX of the license application form their lawyers (behind the times as lawyers always seem to be) finally realized the benefits of the electronic signature act and accept email.
I'm not actually using Perforce at all for my OSS work, so I don't
have anything, sadly. I like hearing what you're saying, though, and
it'll be worth looking at when you release it.
-austin
···
On 4/3/07, Ryan Davis <ryand-ruby@zenspider.com> wrote:
On Apr 3, 2007, at 05:13 , Austin Ziegler wrote:
> It's not going to be something that start-ups use first, though. If I
> were to use Perforce myself, though, I'd set up a public read-only SVN
> repository for others to access.
That is hard to do actually. At least, I haven't found any scripts
that do a good job of it (esp with continual/periodic updates). I'm
finishing up the last of the edge cases on my script to do just that
and will be releasing it "soon". I think all I have left is to delete
empty dirs in svn (which at this point I may just do by hand because
it isn't THAT big of a deal).
If you know of any good scripts for this, I'd love to look at them.
Ryan Davis wrote:
-> I've been running my perforce server for about 8 years running now
and while for a while they were indeed requiring a FAX of the license
application form their lawyers (behind the times as lawyers always
seem to be) finally realized the benefits of the electronic signature
act and accept email.
That's good for them. I got hooked on dVCS when I switched to Arch then
Mercurial so any centralised VCS is out in my book (and P4 is even more
centralised than svn :-)).
I'm even more fine with software that doesn't corrupt repositories, is easy to back up, easy to understand, and works really well / stays out of my way. Perforce is rock solid and has a long standing rock solid history. I _have_ to have 100% complete trust in my VCS and its backups. I simply can't say that about much of any other VCS out there (except the nice stable old ones, like CVS). Too new. Too buggy. Too experimental. Too full of agendas. I just want to get work done.
···
On Apr 4, 2007, at 05:40 , Ollivier Robert wrote:
Ryan Davis wrote:
-> I've been running my perforce server for about 8 years running now
and while for a while they were indeed requiring a FAX of the license
application form their lawyers (behind the times as lawyers always
seem to be) finally realized the benefits of the electronic signature
act and accept email.
That's good for them. I got hooked on dVCS when I switched to Arch then
Mercurial so any centralised VCS is out in my book (and P4 is even more
centralised than svn :-)).
I'm even more fine with software that doesn't corrupt repositories,
is easy to back up, easy to understand, and works really well / stays
out of my way. Perforce is rock solid and has a long standing rock
solid history. I _have_ to have 100% complete trust in my VCS and its
backups. I simply can't say that about much of any other VCS out
there (except the nice stable old ones, like CVS). Too new. Too
buggy. Too experimental. Too full of agendas. I just want to get work
done.
To me, that only sounds like an argument against using Visual Source Safe
As far as backing up an SVN repository (especially if it's using the
file system instead of BDB) tar does a pretty good job.
For the completely paranoid people that are afraid their backup will
be useless in 5 years because software will no longer be available, or
the current version won't read the old version, the svn source code is
small enough to be included on the backup disc.
Speaking as someone who was tasked with setting up and administering a
CVS server for a small team a couple years ago:
AHAHAHAHAHAHAHAHAHAHAHA. CVS stable? Trust CVS with your data? That's rich.
I'm not saying any other system is necessarily better; but treating
CVS as some kind of gold standard of reliability is hilarious. We're
talking about a system that can't even guarantee atomic commits. And
for which maintenance releases sometimes randomly break major features
and have to be manually patched. And which requires having a sysadmin
(or a knowledgeable user) around to periodically clean up orphan
lockfiles which break the repository.
The only thing CVS has going for it is that it is simple,
comparatively speaking. And often that's the most important
consideration. But it's only stable and reliable in comparison to
Visual Source Safe.
···
On 4/4/07, Ryan Davis <ryand-ruby@zenspider.com> wrote:
backups. I simply can't say that about much of any other VCS out
there (except the nice stable old ones, like CVS).
I was expecting to find a SVN UI with the google I just did.
might want to look into svk (try