Am Mon, 6 Jul 2015 15:07:13 +0530 schrieb Mayuresh <mayuresh%acm.org@localhost>: > I believe individual contributors (about whose ease of contribution the > discussion is going on) are not required to deal with such large size. Well, you got some packages that need to be updated in a group. But, generally, you say that people interested in changing something only work on a package directory and it would be a waste to have to download any repository data before it's needed? I see the point for CVS that it is very lean on the working copy, as it only stores some metadata. The use case of the simple tarball having links to the CVS server without noticeable additional payload is an interesting feature, when I think of it. When then, you only do cvs commands on individual packages, I can begin to understand why CVS still works for pkgsrc. Current candidates on revision control have either "pristine" reference files or the history contained in a working copy, which is wasted on the everyday user who doesn't change anything. I see a use case there for Subversion to add a mode where it doesn't include the pristine files in .svn and fetches that information from the server on demand only. > I do not know the nature of files in packaging spec you describe, but in > pkgsrc, it's typically Makefile, distinfo, PLIST and Descr and in some > cases patches. With a typical contributor focusing on 1 package at a time, > I really doubt whether it compares with the scale you are talking about. Oh, it's very similar. In SMGL it's not written as Makefiles, but in bash scripts setting variables and calling Bash functions. You got minimum two files per package, but it can also be more if you need to override defaults or include patches. The files are all rather small plain text, like in pkgsrc. Other source based distros try to keep things collected in one file per package, plus patches. > I use both CVS and git, though not so proficient with the latter. So far > in my usage, which is for closely knit groups, with a centralized > development model, I always found CVS to be simpler. I agree, given you replace CVS with SVN, which is designed to carry on the user interface from CVS and extend it. Apart from the minimal working copy argument above, I cannot fathom a reason for, as a user (and not admin complaining about svn needing heretic libraries like apr;-), continue to use CVS instead. But if it works, it works. The most basic commands are the same with SVN and CVS. I never used tags or branches in CVS and I hope I won't have to. Alrighty then, Thomas -- Dr. Thomas Orgis Universität Hamburg RRZ / Zentrale Dienste / HPC Schlüterstr. 70 20146 Hamburg Tel.: 040/42838 8826 Fax: 040/428 38 6270
Attachment:
smime.p7s
Description: S/MIME cryptographic signature