RE: checking in links to source control
Sidestepping the issue of links in CVS, I'm unclear on the problem you're trying to solve. We have a number of perl scripts stored in CVS which share a large set of common library modules. They work exactly as you describe, in that they are able to bootstrap themselves onto any machine they are checked out onto without any user configuration (except for installing perl itself, of course). For our tool the build for the tool is just to checkout the appropriate module. Access to the libraries is accomplished with a BEGIN block, 'use lib', and some '$FindBin::Bin' trickery. No environment changes needed. Since it seems you have already decided to use a common library location anyway, will this not solve the issue? Admittedly it does not result in exactly the layout you describe with a lib directory below each script, but it works equivalently. Of course, its possible I've missed the point... Alex PS: Though I'm not especially concerned if symlinks become a part of CVS or not, I do feel I must point out that your implementation suggestion gives me two concerns: First it assumes that CVS is a unix-only tool, which of course is not true. Not all platforms have a equivalent to links, and its not clear what clients for these platforms would be expected to do when they came across one of these magic link RCS files. Check out the equivalent tree? They could, but its not really what you would want, and results in file duplication in multiple portions of the tree (files which would get out of sync during commits and updates unless additional local CVS metadata was stored to emulate the link behavior). Second, it mixes revision metadata (checkin comments) with revision content, which in general seems a bad practice to me. -Original Message- From: Edward Peschko [mailto:[EMAIL PROTECTED]] Sent: Monday, September 10, 2001 8:32 PM To: CVS-II Discussion Mailing List Cc: [EMAIL PROTECTED] Subject: Re: checking in links to source control On Mon, Sep 10, 2001 at 06:03:53PM -0400, Greg A. Woods wrote: [ On Monday, September 10, 2001 at 13:33:57 (-0700), Edward Peschko wrote: ] Subject: Re: checking in links to source control I want developers to see - locally - all of the perl libraries cross project. When I do a release, I want people to do a simple 'cvs checkout' to get the entire project, and have it *work on the spot*. Nope. BZT. Wrong. CVS is not a build system. Get a new paradigm. I beg to differ. Why should it *not* be a build system? One of the hallmarks of creativity is to be able to use existing tools in new and interesting ways. Trying to shoehorn a role for a tool simply because it doesn't fit a preconceived view of what a tool should or should not be ain't very smart. And why should I 'get a new paradigm'? The process of making checkout and build one and the same has tremendous benefits - especially if you are dealing with interactive, non-compiled languages. Methinks I smell a bit of compilation prejudice here... (You might be able to hack something together with a script run on checkout, but the last time I tried that it was a major nightmare to get right, and to maintain.) Hence my desire to make cvs work with links. It would be easy enough - all you would have to do is recognize a certain tag on checkout corresponds to a link. and create a link instead of a file. CVS should have link support. Nope. BZT. Wrong again. please stop that childish 'BT' stuff. Its both unprofessional and rude. There's an almost infinite supply of rationale for this decision in the archives too, not the least of which is that RCS can't do it either, and any scheme you might dream up should: a) work with bare RCS; and b) work in such a way that a name in the filesystem can exist, at different times, as a normal file, or a link, or a hard link. I'll bet you'll find meeting those requirements nearly impossible. Well, there are two levels of compatibility possible with RCS: 1) complete compatibility, where there is a one-to-one mapping between an RCS term and a CVS term. 2) compatibility where an RCS directory created by CVS doesn't freak out when used by CVS. If you are talking about definition #1, then well, we are in real trouble because CVS is a superset of RCS and going back and forth between the two is a lossy business. If you are talking about definition #2, then there is a real simple way to make link support 99.9% backwards compatible: 1) if 'adding' a link, make a one-line comment for the file revision, that defines where the link points to. 2) when checking out that link, look for that comment. If it is a link, when checking out, make a link. If not, make a file. 3) if checking in a link (committing it) follow the link to commit the real file
RE: checking in links to source control
Ok, suppose you have a driver script, call it 'bootstrap.p'.
This driver script
goes along with a couple of data files (say an ini file and a
function
library that drives the script (call it instructions.pl)
Now, where should bootstrap.p live? If it lives in a
centralized script
directory, then it is disattached from the files that are
used to drive it, and
its not obvious to the user what they are are supposed to do.
On the other hand, if it lives locally, then its tied to the
particular
data files that are running it. And suppose you want to reuse
the script
for *another* data file, and have that in *another* directory?
Understood. Its not the layout I would have chosen, but that's a
different conversation. In our case very few (if any) scripts are
directly tied to an individual data file, and the data files are always
separate from the code. The relationship between the two is documented,
so the user has to RTM before using arbitrary data with arbitrary
script.
Obviously your need to intermingle code and data in the same (or nearby)
dirs changes that.
And you need to put this FindBin::Bin trickery at the
beginning of each script,
right? I've done that before; it works but its not elegant.
It becomes a real
pain to put that block in front of everything - it also
becomes a lot more
cumbersome to track down where the libraries actually are.
Yes, we do use the same block at the start of every script. It never
struck me as inelegant since it hasn't changed for some time, and comes
as a part of our standardized header comments anyway.
Of course, your layout is different than ours and apparently requires
many more entry points (scripts) than I would have thought, so the
overhead of maintaining that BEGIN block is presumably higher for you.
except the fact that the files are in another location
outside the project
directory and its a pain to trace them down.
As I mentioned in my previous message I'm not here to argue against
symlinks in CVS, just trying to mention a different approach. The notion
that single, presumably well-documented, repository location for
libraries is a pain to find never occured to me. I guess all I can say
is that it works for my application.
No, I'd say that if you want to use links, you know you are
working on a
platform that supports them. No links, and you get a file
that tells you that
its a link.
As for other oses, well, its a bad practice to try to force
onto them something
that they weren't designed to use. However, note that
microsoft and VMS both
have 'links' (microsoft just calls them shortcuts)
And MacOS has aliases, etc. Yes, many platforms have similar structures,
although my experience with MS shortcuts is that they are a far cry from
real links. I'm not actually sure if Win32 perl will treat shortcuts as
links when resolving @INC...
My comment was simply based on the fact that my favorite CVS feature
is that it is a well-behaved cross-platform citizen, and when clients do
non-standard things (like for example storing MacOS resource forks) they
tend to do so in a way that extends without breaking revision extraction
other platforms. Your proposal would not necessarily break other
platforms, but would result in a loss of functionality on those
platforms since they cannot correctly extract the underlying revisions
represented by the links.
It seems to me a more desirable feature for CVS would be to allow
file/directory links within the repository that are not based on
symlinks. While I rarely have a kind word to say about Visual
SourceSafe, it does offer this functionality. So do both StarTeam and
Perforce I believe.
Fine, then make the link a one line file that has a special
tag in it to
signify that its a link - something with the regex:
@link=path
or
@link = @env{whatever}/project/bin.
This would obviously be better.
Alex
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Verifymsg on branches?
Title: RE: Verifymsg on branches? Uwe, I've just finished my first cut at doing per-branch bug number requirements in our CVS repository. Bear in mind I haven't finished testing it yet, so I could be way off base here. It also presumes you are using cvs client/server. My solution was to parse the server-side Entries and/or Entries.Log in the cvs temp directory during msgverify. Any sticky tag (including branches) for the files committed seems to appear there so you can check the sticky tag against a list of known branches (in my case supplied by Bonsai). I'm fairly certain this will not work for the commit -r case Laird mentioned, but since 99% of my users are using GUI CVS clients which do not have a commit -r interface anyway I decided this was a hole I could live with (given no other choice). Loginfo supplies a lot more information than any of the other CVS hooks, the problem for me was that by the time the loginfo runs you can't stop the commit. Its already happened. So while you can warn the user that they didn't include a bug number you can't actually _make_ them do anything at that point. If someone with more CVS hook experience than I knows of a hole in the above suggestion please let me know... Otherwise I hope this helps, Alex -Original Message- From: Uwe Fritsch [mailto:[EMAIL PROTECTED]] Sent: Monday, November 20, 2000 7:38 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Deivanai Meiyappan Subject: Re: Verifymsg on branches? Laird, Thanks for your answer. Instead of changing the entered log message after the user has entered it, I rather would like to make the user aware that he has to enter a Bug ID in the log message. My idea was to have a different log template for the trunk as compared to the branch. As this seems not possible, I now think it would be enough to add the BugID line to the generic template and only do the test whether the Bug ID was entered if the commit is done on the branch. But if you can't check for a tag name at verifymsg this will also not work, right? The only possibility would be to check for a branch version number, i.e. 4 digits instead of 2. How do others enforce that Bug IDs are entered into the log message? Thanks, Uwe. - Original Message - From: Laird Nelson [EMAIL PROTECTED] To: Uwe Fritsch [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, November 14, 2000 7:03 AM Subject: Re: Verifymsg on branches? Uwe Fritsch wrote: we used the verifymsg mechanism in the past to check for some keywords for commit messages. As we create a branch for each release, we would like to add an additional keyword for bug numbers, but only if a new version is committed to the branch. Well, you can't really do this (yes, you SHOULD be able to). This is due to two major things: 1. You cannot get the new version number of a file being committed. So you'll never know if that file is going onto a branch or not. The best you can do is guess based off the old number of the file. This works for most cases, as most users aren't using the -r switch to cvs commit. 2. You can't add anything to the message at commitinfo or verifymsg time. The message being verified is read only. What you *could* do is do something really clever with loginfo. Basically, since loginfo gives you the old and new version numbers, you could invoke cvs admin -m (haven't tried this; don't know if it's supported; rcs -m lets you replace one version's log message with another) if the new revision number contains more than one period in it. The other thing to do would be to apply your new keyword as a tag instead. Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ 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
Taginfo question
Title: Taginfo question I've been looking for this myself, and I believe you are correct. A few weeks ago (in August) one of the OpenAvenue developers posted a patch which provides branch info in taginfo (as well as other information I need in commitinfo, etc.). The patch was for the development version of CVS, not 1.10.8, although a backpatch for 1.10.8 was mentioned. Check the egroups archives for scripting hook patch. Unfortunately I haven't been able to contact the original poster to find out if the backpatch was ever posted anywhere. If anyone knows where the backpatch can be found, I'd appreciate hearing about it. Thanks, Alex -Original Message- From: Laird Nelson [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 14, 2000 7:50 AM To: [EMAIL PROTECTED] Subject: Taginfo question Is there any way to determine from within a taginfo script whether the tag being added is a branch tag? I'm inclined to say no--no such information exists in any of the arguments etc. passed to taginfo, in the ,v file or in the environment. Cheers, Laird
