Re: local changes to CVS tree
On Tue, Sep 11, 2001 at 11:44:26AM -0700, Mark D. Anderson wrote: subversion (apache/bsd, http://subversion.tigris.org/ ) probably the most active effort for an open source replacement for CVS. as of a week ago it just hits its milestone 3, of being self-hosting (it was previously using CVS to keep its own sources). it is still being actively worked on; now is probably not a good time to adopt it. while it intends to supplant CVS, it is inclear to me whether it will support a CVSup equivalent. You're right, this is not the time to adopt it, but I'm keeping an eye on this one - it's actively trying to be easy for CVS users to use, plus it tries to correct CVS's deficiencies, plus they are working on CVS - subversion repository conversion tools. Not to mention the license. Thanks for the pointer! --Stijn -- I'm not under the alkafluence of inkahol that some thinkle peep I am. It's just the drunker I sit here the longer I get. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: local changes to CVS tree
I use perforce at work, and I think it is a really great tool. That said it does have a few drawbacks. For one my experience is that perforce is really only suitable for use in a situation where you are well connected to the server. You can check out a set of files and work with them, but if you want to do things like diff two repo versions you have to be connected to the server at the time. In contrast you can keep a local copy of the cvs repo and do just about everything locally, I haven't found this capability with perforce. Also you can very efficiently fetch the entire cvs repo with cvsup which is really a marvelous tool. I am not aware of a method to do this with perforce. Finally just about my favorite cvs feature is cvs annotate which I have not yet found a way to do under perforce. Do you know of a way to do this? in any scenario, compatibility with existing cvs practices would have to be largely preserved. i was imagining a perforce repository for committers, and a readonly cvs server kept up to date by triggers, to support existing (readonly) practices. this would allow for advanced branching/merging against that perforce repository, without the limitations of cvs. an alternative would be to reverse the relationship, keeping cvs as the master, and constructing perforce slave snapshots. according to kris kennaway, that is already being done for some longer freebsd projects. i don't see how that directly solves the stable vs. current problem, however. cvs annotate can either be done against a slave cvs, or a similar report could be constructed against perforce. it is really just a report, after all. as for the other areas you mention, perforce does not directly support repository-to-repository replication, nor disconnected operations. if replicas are required, rsync (which is not atomic at the database level), or journal playback could be used, though both would require work. i do not know if perforce supports branching against a remote depot; i suspect something like that would accomplish the same goal. but maybe not. the whole question of distributed repositories is kind of a hot button in the CM world, because historically that feature, which clearcase has, was pushed as a solution in circumstances where it was not appropriate, and the simple client-server model works fine (for example, two corporate offices of the same company, both in the U.S.). Finally, what about other version systems does any body have any comments or experience with Ageis, bitkeeper or subversion? and what about that thing the Evind was writing? i don't know anything about Evind; here is a brief summary of some of the other alternatives. all IMHO of course. Aegis (GPL, http://www.canb.auug.org.au/~millerp/aegis/aegis.html ) the pro and the con of aegis is that it enforces a whole change lifecycle, ensuring that submitted changes still compile and pass tests. it seems unlikely that all freebsd committers would care for this approach. If stripped of those abilities, leaving just a source control system, i doubt it is worth it, though i'm sure aegis advocates would disagree. Aegis does have excellent support for name operations (rename/delete/mkdir), one of many things cvs is horrible at. bitkeeper (bitkeeper license, http://www.bitkeeper.com ) bitkeeper was apparently inspired in part by a desire by larry mcvoy to supply linus and linux with a better solution than their current one, although to date there is no sign of it being adopted; judging from the email archive this seems mostly due to it having a free-only-for-free-projects license, though i wonder too if linus ever thought he needed an alternative to begin with. it takes the approach that every workspace is a repository; there is no distinction between a workspace sync and a repository sync; they are the same thing. furthermore, repositories can be placed in a hierarchy. this capability (insofar as i understand it) is used not only for disconnected operations and distributed repositories, but also for what other systems would consider branches or lines of development. if you really feel you need such a distributed model (i.e. distributed repos, not just distributed clients), it is probably worth a look. bitkeeper has its own bitkeeper license. for non open source projects, it allegedly has close-to-clearcase level pricing. subversion (apache/bsd, http://subversion.tigris.org/ ) probably the most active effort for an open source replacement for CVS. as of a week ago it just hits its milestone 3, of being self-hosting (it was previously using CVS to keep its own sources). it is still being actively worked on; now is probably not a good time to adopt it. while it intends to supplant CVS, it is inclear to me whether it will support a CVSup equivalent. PRCS (GPL, http://prcs.sourceforge.net/ ) Josh MacDonald's labor of love. because of his background, has a very strong backend storage mechanism
Re: local changes to CVS tree
Mark D. Anderson [EMAIL PROTECTED] types: as for the other areas you mention, perforce does not directly support repository-to-repository replication, nor disconnected operations. i do not know if perforce supports branching against a remote depot; i suspect something like that would accomplish the same goal. but maybe not. Perforce permits branching from a remote depot, but not to a remote depot - they are read-only. If the goal is to replicate the remote depot, this won't do it. If the goal is to keep local changes to remote depot, it works very well. It will require you to be online to do source udpates, though. While perforce doesn't let you work with it while disconnected, there is a simple procedure to integrate changes made locally while disconnected back to the depot. Personally, I'd love to have access to FreeBSD source via a perforce remote host. On the other hand, I'm biased. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: local changes to CVS tree
On Sat, Sep 08, 2001 at 09:28:27PM -0700, Mark D. Anderson wrote: Terry Lambert [EMAIL PROTECTED] wrote: Any chance of getting CVSup to transfer from a remote repository to a local vendor branch, instead of from a remote repository to a local repository? This would be incredibly useful for building a combined local source tree from multiple project's CVS repositories. It could be used by FreeBSD for a number of contrib things, as well... this has probably been discussed before, but has the freebsd project considered using perforce for the central repository? Yes; see the archives. The main barrier is replication of the p4 depot to local developer machines for offline work. You can extract to cvs, but that's not really good enough. A number of committers are using perforce for out-of-main-tree development work on some of the major projects in -current (SMPng, etc). Kris PGP signature
Re: local changes to CVS tree
Terry Lambert [EMAIL PROTECTED] wrote: Any chance of getting CVSup to transfer from a remote repository to a local vendor branch, instead of from a remote repository to a local repository? This would be incredibly useful for building a combined local source tree from multiple project's CVS repositories. It could be used by FreeBSD for a number of contrib things, as well... this has probably been discussed before, but has the freebsd project considered using perforce for the central repository? perforce runs on freebsd. the company gives free licenses to free software projects, though it is not itself a source-available product. that may bother the religiously open-source, though it really is far superior to CVS. perl5 development has been using perforce; i don't know if they've decided yet what perl6 will use (and in fact that may depend on what sourceforge will supply them). see for example this post on why the perl project is using it: http://www.mail-archive.com/bootstrap@perl.org/msg00589.html as compared to cvs, it has support for views (including both multiple repositories and server-side proxying to other repositories), advanced branching/merging, atomic change sets, and is fast. there are various ways to offer at least readonly cvs access even if committers adopted perforce, as outlined in the link above. (in addition to various master-master and master-slave relationships between perforce and cvs, it should also be possible to have a pserver proxy server fronting over perforce. that would probably be ideal, though i don't think a trustworthy implementation of that yet exists.) -mda To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: local changes to CVS tree
Also sprach Bernd Walter ([EMAIL PROTECTED]): How do people fix stuff in their local CVS tree and sync other FreeBSD changes with that? It's a CVSup FAQ: http://www.polstra.com/projects/freeware/CVSup/faq.html#canilocal Great, thanks. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
local changes to CVS tree
Thus spake Kris Kennaway ([EMAIL PROTECTED]): On Wed, Sep 05, 2001 at 09:52:34AM +0300, Giorgos Keramidas wrote: I have it fixed now in my local CVS tree. Hopefully Kris will commit something to fix it soon :-) I'm just curious: How do people fix stuff in their local CVS tree and sync other FreeBSD changes with that? I mean I have much stuff, which gets M file in the next cvs update, but I'd really like to cvs commit them to my local /home/ncvs, but cvsup will overwrite these changes. Thanks Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: local changes to CVS tree
Thus spake Peter Pentchev ([EMAIL PROTECTED]): One way that (I think it was) Sheldon pointed out to me a few months ago would be keeping your own CVS repository and vendor-importing the FreeBSD source on a regular basis. The regular vendor-import is quite time-consuming though :( That sucks. From what I've heart about the Sparc64 development on freefall, perforce seems to be able to do such stuff automatically, right? Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: local changes to CVS tree
On Wed, Sep 05, 2001 at 01:10:27PM +0200, Alexander Langer wrote: Thus spake Kris Kennaway ([EMAIL PROTECTED]): On Wed, Sep 05, 2001 at 09:52:34AM +0300, Giorgos Keramidas wrote: I have it fixed now in my local CVS tree. Hopefully Kris will commit something to fix it soon :-) I'm just curious: How do people fix stuff in their local CVS tree and sync other FreeBSD changes with that? It's a CVSup FAQ: http://www.polstra.com/projects/freeware/CVSup/faq.html#canilocal -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: local changes to CVS tree
On Wed, Sep 05, 2001 at 01:10:27PM +0200, Alexander Langer wrote: Thus spake Kris Kennaway ([EMAIL PROTECTED]): On Wed, Sep 05, 2001 at 09:52:34AM +0300, Giorgos Keramidas wrote: I have it fixed now in my local CVS tree. Hopefully Kris will commit something to fix it soon :-) I'm just curious: How do people fix stuff in their local CVS tree and sync other FreeBSD changes with that? I mean I have much stuff, which gets M file in the next cvs update, but I'd really like to cvs commit them to my local /home/ncvs, but cvsup will overwrite these changes. One way that (I think it was) Sheldon pointed out to me a few months ago would be keeping your own CVS repository and vendor-importing the FreeBSD source on a regular basis. The regular vendor-import is quite time-consuming though :( Also, I'm not really sure if CVS would allow having two vendor branches (say, RELENG_4 and RELENG_5) and two corresponding working branches (your changes to RELENG_4 and your changes to RELENG_5, which might be *way* different). G'luck, Peter -- Thit sentence is not self-referential because thit is not a word. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: local changes to CVS tree
In article [EMAIL PROTECTED], Peter Pentchev [EMAIL PROTECTED] wrote: Also, I'm not really sure if CVS would allow having two vendor branches (say, RELENG_4 and RELENG_5) and two corresponding working branches (your changes to RELENG_4 and your changes to RELENG_5, which might be *way* different). CVS claims to support multiple vendor branches, but in practice it doesn't work in any useful sense. There's at least one place in the CVS sources where the vendor branch is hard-coded as 1.1.1. You really don't want to use multiple vendor branches -- trust me. :-) Use two repositories instead, or use perforce. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: local changes to CVS tree
John Polstra wrote: CVS claims to support multiple vendor branches, but in practice it doesn't work in any useful sense. There's at least one place in the CVS sources where the vendor branch is hard-coded as 1.1.1. You really don't want to use multiple vendor branches -- trust me. :-) Use two repositories instead, or use perforce. I guess I'll ask the usual question: Any chance of getting CVSup to transfer from a remote repository to a local vendor branch, instead of from a remote repository to a local repository? This would be incredibly useful for building a combined local source tree from multiple project's CVS repositories. It could be used by FreeBSD for a number of contrib things, as well... Just a hint hint to the Modula 3 programmers among us... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: local changes to CVS tree
CVS claims to support multiple vendor branches, but in practice it doesn't work in any useful sense. There's at least one place in the CVS sources where the vendor branch is hard-coded as 1.1.1. You really don't want to use multiple vendor branches -- trust me. :-) Use two repositories instead, or use perforce. I guess I'll ask the usual question: Any chance of getting CVSup to transfer from a remote repository to a local vendor branch, instead of from a remote repository to a local repository? The problem is that you aren't just transferring bits from the HEAD, but from multiple active branches. As John already stated, CVS doesn't handle multiple 'vendor' branches well (and in this case, the FreeBSD tree has vendor (CSRG) branches, FreeBSD vendor branches (RELENG_2, RELENG_3, ..., contrib vendor branches (TCSH, GCC, etc..) CVS is simply not setup to do what you ask. :( Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: local changes to CVS tree
In article [EMAIL PROTECTED], Nate Williams [EMAIL PROTECTED] wrote: Any chance of getting CVSup to transfer from a remote repository to a local vendor branch, instead of from a remote repository to a local repository? The problem is that you aren't just transferring bits from the HEAD, but from multiple active branches. As John already stated, CVS doesn't handle multiple 'vendor' branches well (and in this case, the FreeBSD tree has vendor (CSRG) branches, FreeBSD vendor branches (RELENG_2, RELENG_3, ..., contrib vendor branches (TCSH, GCC, etc..) CVS is simply not setup to do what you ask. :( No, Terry's idea is sound as long as you only try to track one branch of FreeBSD. I.e., you consider FreeBSD to be your vendor, and you do a checkout-mode type of fetch from a branch of the FreeBSD repository and directly import it onto your own vendor branch. This would meet the needs of a lot of people, e.g., companies who make products based on FreeBSD. I have had this on my to-do list for a long time, but I have no idea if or when it'll ever get implemented. It would require a focused period of working on it that I just don't have these days. Maybe if the economy gets worse ... John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: local changes to CVS tree
Any chance of getting CVSup to transfer from a remote repository to a local vendor branch, instead of from a remote repository to a local repository? The problem is that you aren't just transferring bits from the HEAD, but from multiple active branches. As John already stated, CVS doesn't handle multiple 'vendor' branches well (and in this case, the FreeBSD tree has vendor (CSRG) branches, FreeBSD vendor branches (RELENG_2, RELENG_3, ..., contrib vendor branches (TCSH, GCC, etc..) CVS is simply not setup to do what you ask. :( No, Terry's idea is sound as long as you only try to track one branch of FreeBSD. So, you're saying that the person would choose the branch (which may be RELENG_4 *OR* HEAD). I can see how that would work for RELENG_4, but for the HEAD, many of the files on the HEAD in /usr/src/contrib are on vendor branches, which means it would be a *nightmare* to get that right (IMO). I.e., you consider FreeBSD to be your vendor, and you do a checkout-mode type of fetch from a branch of the FreeBSD repository and directly import it onto your own vendor branch. This would meet the needs of a lot of people, e.g., companies who make products based on FreeBSD. Agreed. Although, it may not be as useful to developers, who often have to track development in multiple branches (for MFC's). I have had this on my to-do list for a long time, but I have no idea if or when it'll ever get implemented. It would require a focused period of working on it that I just don't have these days. Maybe if the economy gets worse ... *sigh* Let's hope it doesn't come down to that. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: local changes to CVS tree
In article [EMAIL PROTECTED], Nate Williams [EMAIL PROTECTED] wrote: So, you're saying that the person would choose the branch (which may be RELENG_4 *OR* HEAD). Yep. For instance, a company might have a product that's based on RELENG_4, but with some local mods. So FreeBSD-4.x is in effect that company's vendor. I can see how that would work for RELENG_4, but for the HEAD, many of the files on the HEAD in /usr/src/contrib are on vendor branches, which means it would be a *nightmare* to get that right (IMO). It would still work just the same. You're just checking out -current and importing it onto your own vendor branch. You don't know or care about FreeBSD's vendor branch. Of course (and this is one of the big complications), CVSup would have to map the version numbers somehow. Another big complication would be that at some point in the future a user would want to switch from being based on RELENG_4 to being based on RELENG_5. I have a feeling that could get tricky for CVSup to deal with. Although, it may not be as useful to developers, who often have to track development in multiple branches (for MFC's). Right, it would be pretty worthless for FreeBSD developers. Maybe if the economy gets worse ... *sigh* Let's hope it doesn't come down to that. Just looking for that silver lining. Mom would be so proud of me. :-) John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: local changes to CVS tree
Nate Williams wrote: I guess I'll ask the usual question: Any chance of getting CVSup to transfer from a remote repository to a local vendor branch, instead of from a remote repository to a local repository? The problem is that you aren't just transferring bits from the HEAD, but from multiple active branches. As John already stated, CVS doesn't handle multiple 'vendor' branches well (and in this case, the FreeBSD tree has vendor (CSRG) branches, FreeBSD vendor branches (RELENG_2, RELENG_3, ..., contrib vendor branches (TCSH, GCC, etc..) CVS is simply not setup to do what you ask. :( I know how to make it do it, using a numeric tuple pair prefix to effectively force things onto a vendor branch; CVS will just do the right thing with the data: it's really CVSup, not CVS, which is the bottleneck. I've actually done this one on an experimental basis, by using CVSup to mirror the CVS repository, and then using scripts to hack the holy heck out of the mirror during a copy, which left me with a local repository containing only a skeleton and a vendor branch (with ID's up in the 5000's). It worked, but I got a cramp: the local copy was so expensive compared to an integrated approach, that it was not worth maintaining. It's just been 15 years or so since I did any Modula programming, and the Modula 3 compiler is a behemoth that I'd rather not have to slay to get real work done. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: local changes to CVS tree
John Polstra wrote: No, Terry's idea is sound as long as you only try to track one branch of FreeBSD. I.e., you consider FreeBSD to be your vendor, and you do a checkout-mode type of fetch from a branch of the FreeBSD repository and directly import it onto your own vendor branch. This would meet the needs of a lot of people, e.g., companies who make products based on FreeBSD. Yes, precisely. People always complain that companies are gun-shy of -current; the inability to tag a sufficiently stable version is why most companies stay away from it. This means that most commercially funded work occurs on the -RELEASE/-STABLE branches, for fear of destabilizing their products. Everyone in FreeBSD-land always complains about this, even as they continue to make -current even less stable, and less likely to result in them getting funded help to work on it. So a lot of forward looking research takes a lot longer than it should to bear fruit (or wither, if it turns out to be a net loss). I have had this on my to-do list for a long time, but I have no idea if or when it'll ever get implemented. It would require a focused period of working on it that I just don't have these days. Maybe if the economy gets worse ... I hear Hewlett-Compaqard is laying off 15,000, if that's any incentive... I guess a better question would be whether funding would help? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: local changes to CVS tree
As a workaround, people could just gat the source each week and do an cvs import into the vendor branch via script.. (of course with doing it correctly you could have matching version numbers on the vendor branch) On Wed, 5 Sep 2001, John Polstra wrote: In article [EMAIL PROTECTED], Nate Williams [EMAIL PROTECTED] wrote: Any chance of getting CVSup to transfer from a remote repository to a local vendor branch, instead of from a remote repository to a local repository? The problem is that you aren't just transferring bits from the HEAD, but from multiple active branches. As John already stated, CVS doesn't handle multiple 'vendor' branches well (and in this case, the FreeBSD tree has vendor (CSRG) branches, FreeBSD vendor branches (RELENG_2, RELENG_3, ..., contrib vendor branches (TCSH, GCC, etc..) CVS is simply not setup to do what you ask. :( No, Terry's idea is sound as long as you only try to track one branch of FreeBSD. I.e., you consider FreeBSD to be your vendor, and you do a checkout-mode type of fetch from a branch of the FreeBSD repository and directly import it onto your own vendor branch. This would meet the needs of a lot of people, e.g., companies who make products based on FreeBSD. I have had this on my to-do list for a long time, but I have no idea if or when it'll ever get implemented. It would require a focused period of working on it that I just don't have these days. Maybe if the economy gets worse ... John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: local changes to CVS tree
In message [EMAIL PROTECTED] Terry Lambert writes: : Yes, precisely. People always complain that companies are : gun-shy of -current; the inability to tag a sufficiently : stable version is why most companies stay away from it. For what its worth, I did most of the pccard based work in -current, then switched to -stable for testing/deploying it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: local changes to CVS tree
In message [EMAIL PROTECTED] Julian Elischer writes: : As a workaround, people could just gat the source each week : and do an cvs import into the vendor branch via script.. : (of course with doing it correctly you could have matching version numbers : on the vendor branch) As someone who does lots of vendor branch imports of FreeBSD into cvs, I can tell you that automating it is fraught with dangers if you have any significant changes in your base tree. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: local changes to CVS tree
In article [EMAIL PROTECTED], Terry Lambert [EMAIL PROTECTED] wrote: John Polstra wrote: I have had this on my to-do list for a long time, but I have no idea if or when it'll ever get implemented. It would require a focused period of working on it that I just don't have these days. Maybe if the economy gets worse ... [...] I guess a better question would be whether funding would help? Sure -- that would take care of the my real jobs take priority problem. But I'm currently on two open-ended jobs, which is the most I can manage effectively. So right now I can't guess when I could do it even if I had funding. I'd very much like to do it, but I can't until I've met my existing commitments. John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
