Re: [kfogel@collab.net: Re: rename in cvs]
In article [EMAIL PROTECTED], Greg A. Woods wrote: [ On Saturday, October 13, 2001 at 01:23:14 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] The problem is, I wouldn't hold my breath. You'll certainly turn blue if you try. CVS cannot easily ever support renaming to any extent that something like BitKeeper or Perforce does, at least not without breaking backwards compatabilty of the repository structure. There's simply no place to put the extra meta data necessary except in the commit comments themselves, and you can much more easily build simple little wrapper scripts to do renaming and to drive cvs log, cvs diff, cvs annotate, and cvs update if that's all you're going to do. I've already started the ball rolling, yet again, by posting yet another version of the first such wrapper needed. You're working on this too? I'm going through the design stages of a full blown CVS front end called Meta CVS. The idea is that all you store in CVS is a flat database of files that have completely cryptic, machine-generated names. Along with that, you store a mapping which assigns path names to these objects. On checkout, Meta CVS obtains a sandbox, and then processes the mapping file to create the tree. When you do updates, Meta CVS calculates the difference between the old mapping file and the new (after the user resolves any conflicts) and then rearranges your tree accordingly. If you want to move something, you do it thorugh Meta CVS. It updates its working copy of the mapping file and performs the move. You can then commit to ``make it so''. If the up-to-date check fails on the mapping file, you update, and resolve the conflict. Meta CVS will then move local files around as necessary to reflect your resolution, always keeping a prior version of the mapping file stashed somewhere to determine what rearrangements must be done. I'm thinking of also post-filtering the output of certain cvs commands like rdiff and log. For example, the output of rdiff could be edited to replace the machine-generated names with the mapped pathnames. Not only that, but a POSIX shell script could be prepended or appended to the output, containing mv commands. The idea is that someone with an old version of a tree could execute the renaming script, and then apply the rest of the patch to get to the new version of the tree. Thereby the powers of patch would be effectively extended to doing renaming and directory reshaping. Another idea I have is to implement a whole new tagging system. The project contains a special tag file. When you create a tag with Meta CVS, it adds an entry into the tag file and commits. The entry contains the tag name, and a list of files and their versions. So instead of rewriting every darn tagged file, the baseline information is recorded in one place, so tagging is much cheaper. Moreover, the tag store is itself versioned, so you know when the tag was created and can attach a comment to a tag creation or deletion. Meta CVS can checkout or update to a selected tag by individually pulling out the right revision of each file; an optional patch can be provided for CVS to make this expressible in a single CVS command. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS behind a firewall.
I am trying to access a cvs repository on the net ( lets say CVSROOT=:pserver:[EMAIL PROTECTED]:/home/cvspublic) from a linux machine. The cvs client is version 1.10.8 ( bash is 2.04). We use a proxy server ( SQUID) and a firewall ( ipchains). now whenever I try to access a repository using pserver, I get a timeout. The port number 2401 is open at our end. We opened up all the ports once and tried to connect. I could connect at that time. The client was using port number 1759 at our end. We opened up that too. Still it doesn't work. I've tried repository access with via SSH. It works. Does the cvs client randomly pick up ports at the client end ( in case of pserver)? Can I specify the port to be used at the client side ? Or is there something wrong with our firewalling ( or proxy) software? Is there something wrong with my understanding/expectation ? any help/pointers would be appreciated. Thanks. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [login aborted]: connect to 216.254.34.156:2401 failed: Connection timed out
You seems to have the same problem as me. The firewall systematically block the ports he knows nothing about. Usually they know ftp, web, telnet, ssh, https but cvs is not on the list. Unfortunately, asking your system administrator to open the port seems to be the only solution. And i know this is very difficult. In my case, nobody seems to be able to tell me who the hell is the firewall administrator. So i can't CVS from school Hope this will disespair you, David Delbecq ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS behind a firewall.
Tarun Garg writes: Does the cvs client randomly pick up ports at the client end ( in case of pserver)? Yes. That's the way essentially *all* TCP/IP clients work -- only the server uses a well-known port. Can I specify the port to be used at the client side ? No. Or is there something wrong with our firewalling ( or proxy) software? No. Is there something wrong with my understanding/expectation ? Yours or your firewall administrator's. You need need to configure the firewall to allow outgoing connections from any (non-reserved) port to port 2401. The rule should look almost exactly like the rule for telnet except for the different well-known port number. -Larry Jones The surgeon general should issue a warning about playing with girls. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS behind a firewall.
Thanks Larry. You've solved my problem and improved my basic understanding ( and that of my network administrator too !!). - Original Message - From: Larry Jones [EMAIL PROTECTED] To: Tarun Garg [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, October 13, 2001 10:36 PM Subject: Re: CVS behind a firewall. Tarun Garg writes: Does the cvs client randomly pick up ports at the client end ( in case of pserver)? Yes. That's the way essentially *all* TCP/IP clients work -- only the server uses a well-known port. Can I specify the port to be used at the client side ? No. Or is there something wrong with our firewalling ( or proxy) software? No. Is there something wrong with my understanding/expectation ? Yours or your firewall administrator's. You need need to configure the firewall to allow outgoing connections from any (non-reserved) port to port 2401. The rule should look almost exactly like the rule for telnet except for the different well-known port number. -Larry Jones The surgeon general should issue a warning about playing with girls. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On Saturday, October 13, 2001 at 06:16:25 (GMT), Kaz Kylheku wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] In article [EMAIL PROTECTED], Greg A. Woods wrote: There's simply no place to put the extra meta data necessary except in the commit comments themselves, and you can much more easily build simple little wrapper scripts to do renaming and to drive cvs log, cvs diff, cvs annotate, and cvs update if that's all you're going to do. I've already started the ball rolling, yet again, by posting yet another version of the first such wrapper needed. You're working on this too? No, it's just more or less the same script I've posted a half dozen times in the past every time this issue comes to a head. Others have posted similar scripts in the past too. :-) I'm going through the design stages of a full blown CVS front end called Meta CVS. The idea is that all you store in CVS is a flat database of files that have completely cryptic, machine-generated names. Along with that, you store a mapping which assigns path names to these objects. I alread use a CVS front-end almost exclusively: PCL-CVS. I haven't bothered working on any rename support for it though. Another idea I have is to implement a whole new tagging system. The project contains a special tag file. When you create a tag with Meta CVS, it adds an entry into the tag file and commits. The entry contains the tag name, and a list of files and their versions. So instead of rewriting every darn tagged file, the baseline information is recorded in one place, so tagging is much cheaper. There are a number of very good reasons for paying the price of modifying every file when tagging. You do not want to stray to far from being compatible with plain CVS, or plain RCS for that matter. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
--- Forwarded mail from [EMAIL PROTECTED] [ On Friday, October 12, 2001 at 20:34:48 (-0700), Paul Sander wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] They can be stored in newphrases inside the RCS files, without breaking compatibility. It's still the wrong way to do it, but it's an improvement over the status quo. Well, it could be, but that would break human compatability too, and thus that's about the worst way to put such meta data. Huh??? RCS and CVS can read the files (correctly, and modify them, correctly), and humans aren't supposed to touch the repository directly anyway. And if humans know enough about the RCS file format, they know how to identify newphrases. And the introduced newphrases will be documented, so humans who happen to read the files will still understand them. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
WinCVS: Dates on files
A WinCVS question; I guess actually a general CVS question: Is it possible to preserve the date/time on files when doing an update? I have files that I modified a few months ago, checked them into a new repository, and did an update in a different directory. The dates/times are the current date/time. This isn't a huge deal; it's more a convenience as I consolidate several versions of the project into CVS. Thnx in advance! -- The only thing that helps me retain my fragile grasp on reality is the friendship that I share with my collection of singing potatoes. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Cygwin CVS: local server: storing existing directory
(I sent this to the list on 10/12, but I never saw it. I have the option set to get my posts sent to me.) This should be a no-brainer, but I just can't get my CVS setup going. I'm on Win2k, with Cygwin 1.3.2, CVS 1.11 (the cvs built into Cygwin). I have a directory $HOME/java/sgs that I want to store into CVS. I'm setting my CVSROOT to :local:/cygdrive/c/cvsroot. I want to check out sgs into $HOME/java/cvswork/sgs. Ok, so in the sgs directory, I did this: cvs import -m Simple Grading System sgs intsoft start This appeared to work, creating lots of N and cvs import: Importing ... lines. It did, however, skip importing one source file, because it was in a DIRECTORY named tags. I know why that happened. I'll get that file added once I get everything else working. Anyway, now in /cygdrive/c/cvsroot, there is a sgs directory that contains all of my RCS files. So, now I go to $HOME/java/cvswork and try to figure out how to check it out. I'll show a little bit of shell history here, indicating what I tried. % pwd /home/dmkarr/java/cvswork % cvs checkout sgs cvs [checkout aborted]: must specify at least one module or directory % mkdir sgs % cvs checkout sgs cvs [checkout aborted]: must specify at least one module or directory % cd sgs % cvs checkout sgs cvs [checkout aborted]: must specify at least one module or directory So what am I doing wrong? -- === David M. Karr ; Best Consulting [EMAIL PROTECTED] ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS behind a firewall.
What understanding did you gain? I have the same problem, but do not restrict ANY outgoing ports. In gnu.cvs.help, you wrote: Thanks Larry. You've solved my problem and improved my basic understanding ( and that of my network administrator too !!). - Original Message - From: Larry Jones [EMAIL PROTECTED] To: Tarun Garg [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, October 13, 2001 10:36 PM Subject: Re: CVS behind a firewall. Tarun Garg writes: Does the cvs client randomly pick up ports at the client end ( in case of pserver)? Yes. That's the way essentially *all* TCP/IP clients work -- only the server uses a well-known port. Can I specify the port to be used at the client side ? No. Or is there something wrong with our firewalling ( or proxy) software? No. Is there something wrong with my understanding/expectation ? Yours or your firewall administrator's. You need need to configure the firewall to allow outgoing connections from any (non-reserved) port to port 2401. The rule should look almost exactly like the rule for telnet except for the different well-known port number. -Larry Jones The surgeon general should issue a warning about playing with girls. -- Calvin -- -- William Burrow -- New Brunswick, Canada o Copyright 2001 William Burrow ~ /\ ~ ()() ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
[ On Saturday, October 13, 2001 at 12:34:03 (-0700), Paul Sander wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] Greg A. Woods wrote: [ On Friday, October 12, 2001 at 20:34:48 (-0700), Paul Sander wrote: ] Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] They can be stored in newphrases inside the RCS files, without breaking compatibility. It's still the wrong way to do it, but it's an improvement over the status quo. Well, it could be, but that would break human compatability too, and thus that's about the worst way to put such meta data. Huh??? RCS and CVS can read the files (correctly, and modify them, correctly), and humans aren't supposed to touch the repository directly anyway. And if humans know enough about the RCS file format, they know how to identify newphrases. And the introduced newphrases will be documented, so humans who happen to read the files will still understand them. Obviously you haven't thought through the long term consequences of doing something like that, especially in face of a potentially very wide diversity of how people might access a CVS repository. Hiding such information inside the RCS file in a non-standard extension, i.e. in a way that would make it invisible to standard RCS, or CVS, is not a good idea for a generic solution. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS behind a firewall.
Which incoming ports do you restrict ? You should probably restrict 0-1023,5990-6009,2401(:)),5432 (and a few others). If you restrict them all then no packets can come through unless you set up a specific 2401 tcp proxy server. My strong suggestion is to ask a different mailing list, you'll probably get a better answer. If you're desperate, I can give you an ipchains (need a Linux 2.2 kernel afaik) script that I use and works fine for me. There are a whole bunch of ip firewall scripts on freshmeat. Try one of those. G -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of William Burrow Sent: Saturday, October 13, 2001 3:06 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: CVS behind a firewall. What understanding did you gain? I have the same problem, but do not restrict ANY outgoing ports. In gnu.cvs.help, you wrote: Thanks Larry. You've solved my problem and improved my basic understanding ( and that of my network administrator too !!). - Original Message - From: Larry Jones [EMAIL PROTECTED] To: Tarun Garg [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, October 13, 2001 10:36 PM Subject: Re: CVS behind a firewall. Tarun Garg writes: Does the cvs client randomly pick up ports at the client end ( in case of pserver)? Yes. That's the way essentially *all* TCP/IP clients work -- only the server uses a well-known port. Can I specify the port to be used at the client side ? No. Or is there something wrong with our firewalling ( or proxy) software? No. Is there something wrong with my understanding/expectation ? Yours or your firewall administrator's. You need need to configure the firewall to allow outgoing connections from any (non-reserved) port to port 2401. The rule should look almost exactly like the rule for telnet except for the different well-known port number. -Larry Jones The surgeon general should issue a warning about playing with girls. -- Calvin -- -- William Burrow -- New Brunswick, Canada o Copyright 2001 William Burrow ~ /\ ~ ()() ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
implementing basic metadata in cvs using tags
Hi people, I just had a thought while reading people's emails about renames and preserving unix permissions and so on, and an idea hit me: why not have registered programs on the client side which mangle permissions and so on into a sort of UUencoded string, put into a file's tag, which is then read by the same program and reapplied when the file is checked out? Here's the sketch of where you could use it and what you could do: Example: file has group read, group write, world read, world execute. Then, by some mechanism, you specify that a given file is enabled for this form of tag mangling. upon performing a commit, the client program GETPER say would read the permissions, then encode them as XMKJ1J. That one file gets given the tag META_GETPER_XMKJ1J. When the file is checked out, the checking out procedure knows by the magic META_ that it needs to invoke the external program on that file. It runs GETPER and passes it as a parameter the filename and XMKJ1J. That program knows what to do with it and does so. Example: OCX and COM DLLs used in application may change as the application goes. As an input to the project, they should be included so that you don't trash your machines, re checkout your source and then not be able to compile because they're missing. With this method, you could give them a sticky tag called COM_REGISTER, which then evokes an external program on checkouts/updates and releases, appropriately registering and unregistering the COM file. Maybe even database files could be attached/detached using a similar mechanism? (not sure if this would be useful, but it feels like there would be other similar uses). Example: Well, potentially (this would be a wrap over the top of cvs) -- you could automatically record in a similar format the changes of filenames and then have it intercept log commands to detect when filenames change. Ie. it would store a tag at the point of the creation of the new file which links back to the old file. cvs log is intercepted and generated for both files. they are then somehow concatenated. i recognise this is a much bigger problem but this feature could be a useful stepping stone to getting that working. Forces as I see it are: - need sticky tags to exist in a non-branch context. I don't know if this can be done? If so, then it's simple, I just add an appropriate IS-A tag to a file, and then the appropriate programs are evoked at different points. If this is unavailable, then the only practical way to say this file's unix permissions need to be tracked is to either have some sort of per-module list of files to operate on, or to say for example all html files need to have permissions tracked. We then say that permissions tracked means call GETPER before commits to generate magic tags. - check points where code could run before commits and so on. if this is done as a patch, then this would be the way to go. if not, then this is not necessary since the more messy 'wrap cvs' technique applies. - need to be able to check the tags on checked out files in CVS. i think this is available via cvs log but please let me know if i'm wrong - need tags to be basically constant-time efficiency. a lot of this metadata will get generated, so if it clags cvs then this approach won't work. Could people please: 1. Suggest if there's a better way to solve the COM registration problem? I remember something about the commitinfo and modules files specifying applications to run... ? My offline copy of the cvs manual is broken so i can't look it up. 2. Can I do this just by using built-in functionality or would I need to patch or wrap? 3. Is this useful? It seems to me to solve the whole metadata problem -- you can store file permissions for different platforms and other random information that may be required. People's comments would be greatly appreciated. Regards, Matthew Herrmann --- Far Edge Technology tel: +612 9955 3640 11/80 Mount St North Sydney NSW 2060 Australia ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
