| |
| |
| |
|
Page: 1 2 3
Comments:
<0> well, don't state that all BSDs want to stay with CVS
<0> e.g. on FreeBSD they're clearly looking for something better
<1> they've resisted change so far
<0> yes, but I don't think that's because CVS is better than anything else
<1> well, I think they originally migrated from rcs to cvs :)
<0> mspo: improving speed of CVS is not really a goal of any of the other VCSs, they mostly want to introduce new approaches to the problem
<1> isn't linux back to using a free vcs?
<0> mspo: like, different algorithms to relate changesets, different approaches to the relation developer-project (like a DVCS)
<0> mspo: yes, but not CVS
<1> TGEN- yeah, projects by/for developers are always a little bit like that
<1> experimental
<0> mspo: Linus and his compadres wrote a new VCS from scratch to replace BitKeeper
<1> TGEN- cool
<0> mspo: well, even NetBSD could benefit from a DVCS model, because developer branches in CVS aren't as good as the way you can handle them with a DVCS
<1> TGEN- I'm sure netbsd could benefit from something faster and better
<0> mspo: and some DVCSs also give you powerful tools to merge those developer branches into a 'main' branch without forcing the developers to sync with that tree all the time
<0> like they do when using CVS branches
<1> yeah, I imagine that's pretty tough
<1> trying to track a moving target for major changes
<0> mspo: if you want to improve the speed of CVS, you have to redesign the backend (RCS), so that you don't have to walk a directory tree anymore
<1> that took a ton of time to get out there, even after the work was "done"
<1> TGEN- that's why svn uses bdb
<0> and that by definition makes the repository incompatible with older CVS versions or RCS
<1> TGEN- but not necessarily incompatible with cvs clients
<0> mspo: actually, no, SVN defaults to FSFS these days because BDB database formats change between each new BDB version :)
<1> well, maybe it does
<1> I've never heard of FSFS
<0> making upgrading BDB and/or SVN a pain in the *** if using BDB-backed repositories
<0> FSFS has been the default since Subversion 1.2
<0> mspo: ofcourse, the pserver protocol could remain the same; but if you use CVS_RSH you would need the new version
<0> since the client directly interacts with the repository store
<1> yeah
<0> and older clients expect that repository store to be RCS
<1> TGEN- you'd have to create a virtual directory type of thing
<0> yeah, which introduces the directory tree walking crap again
<0> slwoing you down
<1> which sounds difficult ;)
<0> that too
<1> well
<1> you could map a directory tree to a more efficient memory file or something
<0> you only get the speedup when accessing that memory file ('database') directly with knowledge of how it's laid out inside
<0> otherwise you win nothing
<1> okay
<1> cvs is gnu?
<0> that's why changing to a different VCS makes sense
<0> yes
<1> I say go for it :)
<0> I use Mercurial (Hg) and Subversion myself :)
<0> and some fool ;) is insisting I should try git
<1> subversion seems to be the new popular choice
<1> personally, I think it's okay
<1> although setting up the server is a little involved with the web requirement and stuff
<0> well, Subversion is basically just a better CVS
<0> there's no web requirement for setting up a server
<2> TGEN: git is indeed nice
<0> you can use 'svnserve'
<0> 722 svn 157 0 3944K 964K SLEEP 0:00 0.00% 0.00% svnserve
<1> yeah, I know there are some lighter alternatives
<1> I installed the client-only on my mac
<1> no problem
<3> tgen: do me a favour - try git and then tell me how it is, compared to the others
<0> svnserve is part of the subversion source
<1> netbsd should just add whatever it wants to go to into the default install
<1> and run with it
<0> NedBeasty: I don't think I can do a proper evaluation of all VCSs
<1> I barely kno whow to use cvs/svn
<0> mspo: SVN has the advantage there that it's BSD/MIT licensed
<3> tgen: you should just tell me how git feels :)
<1> so I'm not a good person to test :)
<1> TGEN- sounds like a nice advantage!
<1> TGEN- what about that FSFS thing?
<3> fwiw, i've looked at Monotone recently, and it has a few nice things
<0> mspo: except that it's not a big improvement over CVS, and it's slow for large repositories
<0> mspo: FSFS is a backend store for Subversion which is part of Subversion
<1> isn't there a faster subversion look-alike?
<0> not that I know of
<3> mspo, sure - it's called CVS :-)
<0> haha
<1> I was thinking of SVK
<0> SVK is a hack
<0> you get the disadvantages of SVN, no keyword support (which SVN does have), and a mediocre DVCS model which pales in comparison to the better DVCSs like git or Hg :)
<1> git sounds nice
<1> like it would handle binary files correctly too
<1> at least, I guess
<1> I think svn looks good
<1> I guess rcs is just as good for local repositories
<0> depends on what you want to do with it ofcourse
<3> no
<3> rcs is good for single files only
<3> and if you don't mind locking
<3> (== not have >1 person work on a file... that's what the 'c' in cvs improves)
<3> i use rcs for config files (/etc and others)
<3> helps me see what i've changes with a "ls *,v"
<0> oh, another thing I like about some of the newer (D)VCSs, is the unique hashes for individual changesets, and revision numbers that signify the state of a particular repository, instead of just a file (see hubert's comment regarding what RCS is good for)
<3> <0> ... and which allows real change sets, instead of the stuff that CVS does and that SVN just barely improves
<0> yeah
<0> e.g. darcs and hg do that
<3> l8r
<0> also provides for easy reference to other files changed by a single commit to a repository, instead of having to search and compare log messages for each file in the repository yourself
<4> nagios is the bane of existence
<5> ?
<5> b/c it tells you when things aren't doing what they should be?
<0> NedBeasty: hmm, are all make targets for pkgsrc documented somewhere?
<3> haha
<0> NedBeasty: I just want to extract the *exact* dependency graph before I decide whether or not to try building a package
<3> erm
<3> nfc
<3> ask whoever decided it's a good idea to not traverse the full path
<0> hm
<0> where's agc when you need him (on irc)
<3> not at all?
<0> he has shown up here on a couple of occasions last year
<0> or the year before
<6> He has?
<0> yeah
<1> alright. Time for lunch
<0> alright. Time for dinner
<0> ****, you added an extra space
<4> because by default it calls /usr/bin/mail -s
<4> which ****s
<4> how hard is it write: /usr/bin/printf "From: foo\nTo: bar\nSubject: hate\n\n foo biz bang bar\n"
<4> and pipe it to "sendmail -t"
<4> which is 1000-times more platform independant than mail(1)
<7> why does X need INSECURE on i386 port but not on other ports?
<6> because of how it accesses the hardware
<7> ahh
<0> yeah, I heard the aperture driver has been broken for some time
<1> I think I'll start using svn for my local stuff
<8> a $1500 item was missing from a recent dell order. i called them to report it. they said they would look into it, and in 48 hours would decide what to do. the next day the part showed up. i reported it, and they said they would close the case.
<8> a couple weeks later, another one shows up, even though i did not order it
<5> heh
<5> i RARELY have issues with dell stuff
<5> but i've learned when you do it ****s hard
<8> I worked up the courage to tell them about it
<8> it'd be nice if they let me keep it, i could put it to use
<8> any recommendations on a box to physically secure a PC?
<8> I want to be able to lock it, and it needs to have air p***age and p***age for cables, but I do not want I/O ports to be accessible
<5> i have a cabinet for that
<8> http://www.iscdfw.com/onlinecatalog/dvr/dvr.htm
<8> looks promising
<1> get a closet with a key :)
<8> this needs to be on a shop floor
<5> ack
<1> ahh
<8> top sekrit codez
<8> no network, no access for corporate espioneers
<1> cool
<1> just shop floor workers? :)
<8> yes
Return to
#netbsd
or
Go to some related
logs:
#freebsd
yunk-punks
#unixhelp
jerome niginla
#beginner
#worldcup
#eggtcl
enterbelladona
bot terarist
#beginner
|
|