O
Ollivier Robert
Jan said:
Well, it is cheap in git as it is in svn, the differences are not
there... The distributed/decentralised model is the biggest difference.
Well, it is cheap in git as it is in svn, the differences are not
there... The distributed/decentralised model is the biggest difference.
O
Ollivier Robert
Ryan said:
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.
J
Jan Friedrich
The main difference is for me that in svn the branch is a part of theOllivier said:
hole history of the repository while in git a can simple delete a branch
and it is not any more existent. Therefore I use it in many cases when I
don't know if an idea is best way to solve a particular problem. If I
want to do it this way, I merge it to the master and delete the
temporary branch. Otherwise I delete the branch also and don't see it
again. This is my definition of cheap: temporary branches.
M
MenTaLguY
In my experience that isn't really true -- git has much better merge tracking than svn, so repeated merges on long-lived branches are substantially less painful with git.
-mental
R
Ryan Davis
It isn't _that_ much of a PITA for the benefits of using perforce for
free.
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.
R
Ryan Davis
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.
A
Austin Ziegler
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
O
Ollivier Robert
MenTaLguY said:
Yes, this is a major drawback of current svn (although svk sorta fixes
that problem). svn has more problems anyway
Disclaimer: I'm the author of a paper on using dVCS on FreeBSD with
focus on Arch & Mercurial.
O
Ollivier Robert
Ryan Davis wrote:
-> I've been running my perforce server for about 8 years running now
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've been running my perforce server for about 8 years running now
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
).
M
Mike Stok
Yes, this is a major drawback of current svn (although svk sorta fixes
that problem). svn has more problems anyway
Disclaimer: I'm the author of a paper on using dVCS on FreeBSD with
focus on Arch & Mercurial.
Is this paper available anywhere?
Mike
--
Mike Stok <[email protected]>
http://www.stok.ca/~mike/
The "`Stok' disclaimers" apply.
R
Ryan Davis
Ryan Davis wrote:
-> I've been running my perforce server for about 8 years running now
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 totally fine with centralized VCS.
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.
K
Kyle Schmitt
I'm totally fine with centralized VCS.
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.
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.
R
Ryan Davis
To me, that only sounds like an argument against using Visual
Source Safe
Well, that's just a given.
I think this is part of the problem. I don't want to think about what
storage mechanism it uses (past an evaluation stage at least). I
don't want to have to think: Did they test this storage format as
well as the previous? What are the repercussions of using this over
the other (eg http vs svn protocol)? I just want it to work so I can
do the same.
I've seen too much SVN corruption already to trust it.
C
Clifford Heath
Ryan said:
Using the BDB store or files?
R
Ryan Davis
Should it matter? SVN corruption is SVN corruption.
That said, I dunno. I wasn't privy to the server's setup.
D
Devin Mullins
R
Ryan Davis
Does? No. ANY (recent) amount is too much. There are enough options
available where I don't need to pick from the scary ones.
R
Ryan Davis
This is the last I'll speak on this topic. I promise...
% curl -s http://svn.collab.net/repos/svn/trunk/CHANGES | egrep -ic
"dataloss|corrupt"
16
Including... SURPRISE! In the very latest release!!! and 5 in the
last year alone (since sept 2006 actually).
So does the storage type matter??? Hell no. Not with that track record.
M
Marcin Gil
Ryan said:
The only problem with Perforce is money.. Lots of them.
Of course in professional businesses it is a question
"money or safety". Sad that often money option wins..
As for private/small team use Subversion is quite good.
I've also been trying out Bazaar and it looks good too.
http://dentharg.wordpress.com/2007/02/14/bazaar-ng-private-repositories-on-shared-hosting/
Cheers,
-Marcin
A
Austin Ziegler
1. For open source projects, Perforce can be free.
2. For commercial projects, it often is a matter of "you get what you
pay for." Part of the benefit of Perforce is rock-solid technical
support. You *pay* for the support in terms of a per-user annual
contract, but that doesn't change the quality of the support you get
(I am speaking from personal experience here).
There are things that you need to understand with Perforce, and i'm
sure we're not taking advantage of a quarter of what Perforce actually
offers us (and could probably boost performance without having boosted
the hardware), but if I were a company, I wouldn't want to use
anything else for my primary source repository.
-austin