Re: Working on sources in parallel
CVS notices the conflicting changes and produces a working copy of the file that contains Person1's removed lines and Person2's inserted lines, with special mark-ups to draw attention to the problem. It also leaves copies of both contributors in the user's workspace. On Jun 15, 2005, at 10:44 PM, [EMAIL PROTECTED] wrote: I have another question. Let's stick to the scenario Christopher made up. Say person1 thinks it'd be a good idea to remove some helper-function foo(), and replace it with another function bar(). Then he commits the sources. Person2 still works on the outdated source, where foo() exists, and he thinks it'd be a good idea to introduce a new variable or whatever in foo(), so his changes to the file are limited to the function foo. Now he wants to commit his changes, and CVS complains sorry bro, update first. Okay, so he does an update, and... now what? What does CVS do in such a situation? How could it merge the two sources, with changes to a function foo() which was removed by person1? So many questions :) -- Matthias Kaeppler ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs -- Paul Sander | Lets stick to the new mistakes and get rid of the old [EMAIL PROTECTED] | ones -- William Brown ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: $id automatically inserted in file
On May 25, 2005, at 5:08 AM, [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Klaus Hebsgaard wrote: Hello I am using cvs for keeping some html files, in these html files i have strings like $id$. cvs sees this and think it is suppose to add it logging in here. However I don't want this to happen. Is there some way to prevent cvs from writing anything to the file? Separate or change the case of $Id$. Something that looks like '$I d$' or '$id$'. You might also look into what cvs admin -ko and cvs admin -kk can do for you. -- Paul Sander | Lets stick to the new mistakes and get rid of the old [EMAIL PROTECTED] | ones -- William Brown ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs editors funny
No, it's not. But in your last message you seemed rather upbeat about finding the path of the workspace having been squirreled away. I'm just pointing out that you can't hope for a solution to this problem unless the workspace and repository can both agree on an identity for the workspace. Comparing the present working directory of the client with a stored workspace path will likely not satisfy this requirement. Storing the present working directory of the client in the workspace at the time it was created, and using that stored value, would satisfy the requirement. On Mar 30, 2005, at 7:08 AM, [EMAIL PROTECTED] wrote: Paul Sander wrote: Be careful here. The location appears to the directory identified by the client at the time the edit was done. Due to network mounts, this path is not unique. So when editing, unediting, or committing a file, there's really no way to know if the workspace you're affecting is really the one recorded by a prior edit. True, but is that significantly different than the following scenarios: cvs co project cd project cvs edit file cd .. mv project proj2 or: cvs co project cd project cvs edit file cd .. rm -rf project Or am I missing something? -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) -- Paul Sander | Lets stick to the new mistakes and get rid of the old [EMAIL PROTECTED] | ones -- William Brown ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs editors funny
Be careful here. The location appears to the directory identified by the client at the time the edit was done. Due to network mounts, this path is not unique. So when editing, unediting, or committing a file, there's really no way to know if the workspace you're affecting is really the one recorded by a prior edit. On Mar 29, 2005, at 6:22 AM, [EMAIL PROTECTED] wrote: Colm Aengus Murphy wrote: The current cvs edit command stores the users name and workspace location in the fileattr file. I'm guessing that when you unedit or checkin it it only matching the users name and not the workspace location. How difficult would it be to check the users name and workspace location and only remove the edit if it matches ? Huh, whaddya know - it looks like CVS already captures that information. I issued a 'watch on' and 'edit' on a .cvsignore file, and the fileattr contains: F.cvsignore _watched=;_editors=jhyslopTue Mar 29 14:13:46 2005 GMT+01-2189+E:\cvs\cvs-test\jhyslop; _watchers=jhysloptedit+tunedit+tcommit The datestamp and path are displayed when you issue 'cvs editors'. It only stores one per user, though - I checked out the project into a different directory, issued the 'cvs edit' command and got: F.cvsignore _watched=;_editors=jhyslopTue Mar 29 14:16:07 2005 GMT+01-2189+E:\cvs\cvstest2;_watchers=jhysloptedit+tunedit+tcommit So the infrastructure may be there already. It may not be as difficult as I thought. We do find that old edits hang around when uses forget to use unedit and just remove the workspace. This isn't a major pain as you can just edit the fileattr to remove the unused edits. Ick - I hate having to manually edit the file (we have a lot of people who have left, but forgot to 'cvs watch remove' before they left). One of these days, when I have the time, I'm going to work on implementing rwatch and redit commands, with options to specify the user. -- Paul Sander | When a true genius appears in the world, you may [EMAIL PROTECTED] | know him by this sign: that all the dunces are in | confederacy against him. -- Jonathan Swift, writer. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs editors funny
On Mar 24, 2005, at 7:00 AM, [EMAIL PROTECTED] wrote: Colm Aengus Murphy wrote: We've come across the following funny when using the cvs editors feature. In my workspace I do a cvs edit to indicate I am editing a file. cvs editors correctly reports me as an editor. If I then create another workspace using cvs co and run cvs editors I am no longer listed as an editor of the file. Darren Bowles submitted a patch to correct this, on the bug-cvs list, two days ago. Is this a good demonstration of statistical clustering, or what? :=) Another funny is that you can only be listed as an editor of a file once even though you might be editing the same file in more than one workspace. Well, this one's a bit trickier. The repository does not keep track of how many locations you have a workspace checked out (except _maybe_ in the history file). Seems to me keeping track of which locations you're editing and which you aren't would be an administrative nightmare, getting into situations that could be extremely difficult to correct. For example, suppose a user checks out a project, issues 'cvs edit' on one or more files, then abandons the changes by simply deleting the working copy. In order to release the edit, the user would have to re-create the exact same directory structure, then issue the 'cvs unedit' command. You don't have to store the actual locations in the repository. (Doing so is pointless anyway given that mount points can appear and disappear non-deterministically.) Just store an identifier there, which could be as simple as an Ethernet-address/timestamp/pid triple. (I suggest Ethernet address because it's guaranteed to be unique to the interface, and Ethernet is pretty common. It doesn't really matter what the identifier is, as long as it's unique. The server could also conjure one up when the client creates a new workspace.) The identifier must be stored in the workspace as well. In the event that a workspace references multiple repositories, it can have multiple identifiers matching each repository. Yet another approach would be to generate the identifier on the client from the host's FQDN and fullpath to the top of the workspace at the moment the client creates it. It won't necessarily be the actual location where the user did any specific edit, but solves the requirement of tracking edits per workspace, and it also provides a means to start searching for a workspace should it be necessary. When listing editors, users may be listed multiple times, and identifiers matching the user's workspace can be highlighted (or identifiers not matching the workspace can be omitted). When unediting or committing work, remove the edit record matching the user and the workspace identifier. When removing a workspace, remove all edit records matching the workspace identifier. Provide administrative functions to list editors with workspace identifiers and to remove editors matching a specific workspace identifier. -- Paul Sander | To do two things at once is to do neither [EMAIL PROTECTED] | Publilius Syrus, Roman philosopher, 100 B.C. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Parsing Loginfo-Information needed
If you have direct access to your repository, then take a look at the rinfo program, which produces such output in a way that's easy to scan automatically. Otherwise, you'd be well advised to learn awk or perl, which are good at scanning complex output like this. The rinfo program is located at: http://www.wakawaka.com/source.html --- Forwarded mail from [EMAIL PROTECTED] I used the following command cvs log -NSb -r -d 2005-03-22 It displays lot of information . What I need out of that is only the filename, latest revision number and author and the comment. I am very bad in parsing the output. Please helpme out. RCS file: /cvs_prod/CENTREXMATE/FRONTEND/CentrexMateWeb/WebContent/pages/verify/ vpo.jsp,v Working file: CentrexMateWeb/WebContent/pages/verify/vpo.jsp head: 1.4 branch: locks: strict access list: keyword substitution: kv total revisions: 4; selected revisions: 1 description: revision 1.4 date: 2005/03/22 22:19:27; author: ar7314; state: Exp; lines: +3 -3 R37_WR102340_corrected DIV tag --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Idea for reducing disk IO on tagging operations
Everything that Mark says is true. I'll add that some shops optimize their read operations under certain conditions, and such optimizations would break if the RCS files are updated in-place. What happens is that, if the version of every file can be identified in advance (using version number, tag, or branch/timestamp pair) then they can invoke RCS directly to fetch file versions, read metadata, and so on. This sidesteps CVS' overhead and can increase performance by as much as 50%. Such operations will also succeed and not interfere with write operations to the repository, such as commits and the creation of new tags. Moving tags or using cvs admin may sometimes cause race conditions that produce incorrect results, but that all depends on the nature of the changes being made at the time and how the readable versions have been identified. The reason that such an optimization works is because RCS rewrites the RCS file updates into the lock file, filesystem semantics always keep the complete RCS file intact while it's being read, and pre-existing data in the RCS file are not changed during write operations (except for those race conditions I've identified above, which can be avoided). On Mar 20, 2005, at 8:28 AM, [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dr. David Alan Gilbert [EMAIL PROTECTED] writes: So - here are my questions/ideas - I'd appreciate comments to tell me whether I'm on the right lines: 1) As I understand it the tag data is the first of the 3 main data structures in the RCS file (tag, comments, diffs) and that when I do pretty much any CVS operation I rewrite the whole file - is this correct? CVS write operations on a foo.c,v repository file will write ,foo.c, and then when the write operation is successful and without any errors, it does a rename (,foo.c,, foo.c,v); to make the new version the official version. While the ,foo.c, file exists, RCS commands will consider the file locked. It is desirable to use RCS write semanitcs as many other tools out there (cf, ViewCVS) use RCS on the repository and want to obey RCS locking. 2) White space appears to be irrelevent in RCS files; so adding arbitrary amounts in between sections should leave files still fully compatible with existing RCS/cvs tools. Tools such as CVSup by default will canonicalize the whitespace between sections (although this may be configured). So, yes, whitespace is mostly irelevent between sections. 3) So the idea is that when I add a tag I add a bunch of white space after the tag (lets say 1KB of spaces split into 64 byte lines or similar); when I come to add the next tag I check if there is plenty of white space, if there is then instead of rewriting the file I just overwrite the white space with my new tag data; if there is no space then as I rewrite the file I add another lump of white space. This has the potential to more easily corrupt the RCS file if the operation is interrupted for any reason. 4) Whether dummy white space is added and how much is controlled by the existing size of the RCS file; so an RCS file that is only a few KB wont have any space added; that way this mechanism doesn't slow down/bloat small repositories. The amount of white space might be chosen to align data structures with disk block boundaries. 5) My main concern is to do with concurrency/consistency requirements; is the file rewrite essential to ensure consistency, or is the locking that is carried out sufficient? Does this make sense? It would be more robust to enhance CVS to use an external database for tagging information instead of putting the tagging information into the RCS files directly than to rewrite parts of the RCS file and hope that the operation didn't corrupt the file along the way. You may wish to consider looking at Meta-CVS as I believe that Kaz keeps a lot of the branching information outside of the RCS files already. See http://users.footprints.net/~kaz/mcvs.html for more details on Meta-CVS. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCPaS23x41pRYZE/gRAjULAJ9RzLHw+gUDoMCbF0zjgmStBJIT9gCfUU83 K/TZMZdXbJx+BWVFaXGS0Jk= =fz6n -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs -- Paul Sander | When a true genius appears in the world, you may [EMAIL PROTECTED] | know him by this sign: that all the dunces are in | confederacy against him. -- Jonathan Swift, writer. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Idea for reducing disk IO on tagging operations
On Mar 20, 2005, at 3:54 PM, [EMAIL PROTECTED] wrote: * Mark D. Baushke ([EMAIL PROTECTED]) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dr. David Alan Gilbert [EMAIL PROTECTED] writes: OK, if I create a dummy ,foo.c, before modifying (or create a hardlink with that name to foo.c,v ?) would that be sufficient? I would say that it is likely necessary, but may not be sufficient. Hmm ok. Or perhaps create the ,foo,c, as I normally would - but if I can use this overwrite trick on the original then I just delete the ,foo.c, file. I am unclear how this lets you perform a speedup. I only create the ,foo.c, file - I don't write anything into it; the existence of the file is enough to act as the RCS lock; if I can do my inplace modification then I delete this file after doing it, if not then I proceed as normal and just write the ,foo.c, file and do the rename as you normally would. You're forgetting something: The RCS commands will complete read-only operations on RCS files even in the presence of the comma files owned by other processes. Your update protocol introduces race conditions in which the RCS file is not self-consistent at all times. There's also the interrupt issue: Killing an update before it completes leaves the RCS file corrupt. You'd have to build in some kind of crash recovery. But RCS already has that by way of the comma file, which can simply be deleted. Other crash recovery algorithms usually involve transaction logs that can be reversed and replayed, or the creation of backup copies. None of these are more efficient than the existing RCS update protocol. So the issue is what happens if the interrupt occurs as I'm overwriting the white space to add a tag; hmm yes; Correct. Depending on the filesystem kind and the level of I/O, your rewrite could impact up to three fileblocks and the directory data. is it possible to guard against this by using a single call to write(2) for that? Not for all possible filesystem types. You'd have to guarantee that the write is atomic and flushes results completely to disk, even in the presence of things like power failures. It's hard to make this guarantee given all the buffering that goes on below the write(2) API. Optimizing for tagging does not seem very useful to me as we typically do not drop that many tags on our repository. In the company I work for we are very tag heavy, but more importantly it is the tagging that gets in peoples way and places the strain on the write bandwidth of the discs/RAID. I once built a successful system that tracked desirable configurations by building lists of file/version pairs, then committing and tagging the lists. The lists were built by polling the Entries files in workspaces (and making sure there were no uncommitted changes). This was fast and efficient, and it opens you up to use the optimization I mentioned earlier. And if you rely on floating tags, such lists could track the history of the tags as well. In addition, an algebra can be easily written to manipulate such lists. Combine this with a way to link these lists with your defect tracking system, and you have the tools to build a very good change control system. -- Paul Sander | Lets stick to the new mistakes and get rid of the old [EMAIL PROTECTED] | ones -- William Brown ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS and tracability
You can also use rcsinfo to prompt the user for a defect ID and use loginfo to record the modified files and version numbers in your defect tracking system. Done right, you also get the ability to query for bugs fixed in a given build. On Mar 6, 2005, at 3:06 AM, [EMAIL PROTECTED] wrote: I'm faced with the requirement to trace changes due to certain bugfixes, i.e. to answer questions like which files have been affected by change request 1234. Currently, the only way I can think of to answre question like this is using the taginfo mechanism. Are there any examples I could use? Other approaches? -- Paul Sander | Lets stick to the new mistakes and get rid of the old [EMAIL PROTECTED] | ones -- William Brown ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Long version numbers | Tedious to keep track
One of the problems with using tags is that developers can and sometimes do move them around. This was a serious concern for me at one time, and it's one of the reasons why my preferred change control and build audit methods pass around lists of file names and version numbers. If this is of concern to you, then see if you can build a suitable access control mechanism using taginfo. It has the ability to halt a tag or rtag operation if the script you supply exits with a non-zero status. On Mar 2, 2005, at 5:28 AM, [EMAIL PROTECTED] wrote: It is not clear from your message why you need to use the rcs version numbers. If you are already using tags then you seem to have missed the point of why they are useful. I can't imagine a reason why you couldn't just tell somebody the tag name and have that be good enough. Maybe I just don't understand what you are trying to do, however. -- Paul Sander | Lets stick to the new mistakes and get rid of the old [EMAIL PROTECTED] | ones -- William Brown ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: 'checkoutinfo' trigger?
What are the modes of your directories right now? If you turn off world read and execute access to an ancestor directory, users can't penetrate the choke point without an ACL that accommodates your access policy. This won't work with pserver, of course. I'm glad to see another suggestion for a more complete set of triggers, even if they would affect what users can do to their own workspaces. On Feb 23, 2005, at 8:36 AM, [EMAIL PROTECTED] wrote: In our repository, we would like to be able to set up permissions so that specific groups of people (in particular, co-op students who are only with us for four months) can only check out from specific areas of the repository. In general, full-time staff have access to most, if not all, areas of the repository. We currently use permissions, groups and ACLs at the operating system level to achieve this, however there are drawbacks. Full-time staff are in one group, and co-op students are in different groups. When one group adds a directory to the repository, the other group cannot access that directory until its ACLs are updated. This is usually done automatically by an overnight cron job, but it can be run on-demand. The cvs_acls script is great for this kind of control - but it only works at check-in, not at check-out (we don't want our co-op students checking out significant portions of the repository, burning it to a CD and selling our intellectual property to our competitors). For us, an equivalent to the 'commitinfo' which runs at checkout-time would be very useful. The trigger would behave the same - an exit code of 0 allows the checkout to proceed, and a non-zero exit code aborts the checkout. Are we unique in this requirement, or are there other people on this list who would find a checkout trigger useful? -- Paul Sander | When a true genius appears in the world, you may [EMAIL PROTECTED] | know him by this sign: that all the dunces are in | confederacy against him. -- Jonathan Swift, writer. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: braches best usage
create a little overwork.. What's the best thing to do? I'm a bit lost... Best regards, Bobby _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs -- David A. Bartmess Software Configuration Manager / Sr. Software Developer eDingo Enterprises http://edingo.net _ jSyncManager Development Team (http://www.jsyncmanager.org) jSyncManager Email List (https://lists.sourceforge.net/lists/listinfo/jsyncmanager-devel) But one should not forget that money can buy a bed but not sleep, finery but not beauty, a house but not a home, medicine but not health, luxuries but not culture, sex but not love, and amusements but not happiness. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs -- Paul Sander | When a true genius appears in the world, you may [EMAIL PROTECTED] | know him by this sign: that all the dunces are in | confederacy against him. -- Jonathan Swift, writer. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: jar files in cvs repository
I'm not really answering your question as I have not done any kind of timing analysis on the various storage methods. However, I have seen other systems that use the following methods. Based on their algorithms, one would expect these to be listed in order of decreasing speed for arbitrary versions. One would also expect these to be listed generally in order of decreasing space, though the last three are roughly equivalent. - Store each version intact, - Store each version intact, compressed, - Store versions using xdelta, - Store versions using interleaved deltas (like SCCS), - One RCS file per file/branch pair (each branch gets its own RCS file), - Store versions using purely reverse-deltas (like RCS). Note that the performance characteristics of the various delta algorithms may make retrieving certain specific versions faster than the others. For example, RCS stores the most recent HEAD version intact so it's the fastest to retrieve, and RCS slows down depending on how many versions live between the desired one and the HEAD. Xdelta stores several versions this way and uses reverse deltas (but using a more efficient differencing algorithm than RCS does) so there are more fast versions and a cap on the number of deltas to apply. SCCS on the other hand uses a method more akin to #ifdef to conditionally build each version in just one pass, so it will take roughly the same amount of time to fetch any given version, which is slower than decompression or copying directly but faster than applying many diffs. I've also seen a system compress versions before checking them in to RCS, which was a bad idea. I've also personally modified old versions of RCS and CVS to compress the RCS files to get a space advantage but with slightly degraded performance. On Feb 20, 2005, at 11:55 PM, [EMAIL PROTECTED] wrote: I'm not sure of the speeds, but it's a two-edged sword. Keeping full copies of everything bloats the database requirements for CVS, making the disk space an issue. And I couldn't say whether not using the diff to create deltas to keep instead would be faster or slower than checking in a full copy every time. But for source code, etc, I'd quickly say that checking in a full copy is a waste, since it's not that big usually, and the time differences would be minimal... Maybe someone else has actually done timing on this? On Monday 21 February 2005 12:39 am, Jesper Vad Kristensen wrote: David Bartmess wrote: Used in the cvswrappers file, the -m gives the mode of the file to the cvs admin command, setting the mode of the file to either COPY (do not delta the file, put a full version in every time) or to MERGE (put only delta of file changes into the repository)... On Friday 18 February 2005 01:28 am, Jesper Vad Kristensen wrote: Larry Jones wrote: It's better to do: *.[Gg][Ii][Ff] -k 'b' -m 'COPY' (Amazing what you can do in CVS!) But why the -m 'COPY'? That's very interesting. We're working with binary source code here and have some performance issues when retrieving stuff from branches (due to the backtracking or whatever it's called). Would you - or anyone else here - happen to know if storing the whole copy of the file each time speeds up retrieval in branches? Regards, Jesper Vad Kristensen ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs -- David A. Bartmess Software Configuration Manager / Sr. Software Developer eDingo Enterprises http://edingo.net _ jSyncManager Development Team (http://www.jsyncmanager.org) jSyncManager Email List (https://lists.sourceforge.net/lists/listinfo/jsyncmanager-devel) But one should not forget that money can buy a bed but not sleep, finery but not beauty, a house but not a home, medicine but not health, luxuries but not culture, sex but not love, and amusements but not happiness. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs -- Paul Sander | To do two things at once is to do neither [EMAIL PROTECTED] | Publilius Syrus, Roman philosopher, 100 B.C. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Undo check out
You don't. CVS doesn't have the notion of a traditional checkout that involves locking. There may be a record in history that a workspace has been created (which is what CVS calls a checkout) that can be countered by invoking the cvs release command. If, on the other hand, someone is trying to simulate a reserved checkout mechanism using the cvs admin command, there's a different option to that command that clears the RCS level lock. But using cvs admin in this manner is strongly discouraged. On Feb 15, 2005, at 10:16 PM, [EMAIL PROTECTED] wrote: I have wrongly checked out a compononet. How will I undo this checkout. Removing lock manually is one option but is there any other better way to do this. -- Paul Sander | When a true genius appears in the world, you may [EMAIL PROTECTED] | know him by this sign: that all the dunces are in | confederacy against him. -- Jonathan Swift, writer. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Can I turn off merge conflict markers?
Still another method, not for the faint at heart, is to apply my patch
from September 2001 that allows a site to install their own merge
tools. Perhaps even easier would be to read the name of the diff3
program from an environment variable. Then install a wrapper that does
what you want.
On Feb 10, 2005, at 9:08 AM, [EMAIL PROTECTED] wrote:
Todd Denniston wrote:
Mark E. Hamilton wrote:
[EMAIL PROTECTED] wrote:
When you get a file where automatic merge fails
CVS will report a merge conflict and then modify
the offending file with conflict markers:
...which is fine most of the time, but now I have a situation
I believe Mark's responses are correct, but you might be able to use
some
other commands to deal with it the way you want.
1. make separate lists of files with and without conflicts (look for
C in
the output of update).
cvs -n update 21 | \
process_to_separate_filenames_with_conflicts 2. just update those
without conflicts.
for i in `cat files_without_conflicts`; \
do cvs update $i;done
3. do something special for the ones with conflicts.
for i in `cat files_with_conflicts`; \
do marks_method_1or2 $i;done
marks_method_3 is the only known correct method, but your situation
might be
special.
A fourth approach would be to do the 'cvs update' to merge everything
that can be merged successfully, and then use something like this to
automatically select one of the two choices in the conflict lines:
#!/bin/bash
for file in $(cvs -q update | egrep '^C' | cut -f2 -d' ')
do
# Pick one of these two sed commands.
# This will discard the repository changes and keep the project changes
sed -e '/^===/,/^/d' -e '/^/d' ${file} blarg \
mv blarg ${file}
# This will discard the project changes and keep the respository
changes
sed -i -e '/^/,/^===/d' -e '/^/d' ${file} blarg \
mv blarg ${file}
done
--
Mark E. Hamilton
Orion International Technologies, Inc.
Sandia National Laboratory, NM.
844-7666
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
--
Paul Sander | To do two things at once is to do neither
[EMAIL PROTECTED] | Publilius Syrus, Roman philosopher, 100 B.C.
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Medium sized binaries, lots of commits and performance
Larry gave a great description of why you're seeing your performance degrade over time. As you can see, the more versions sit between the head and the version you want, the longer it takes to construct the version you want. I can think of two effective and usable ways to combat the problem, plus one marginal one. All of them essentially move the version you want closer to the head. The first method is your MIGRATE method, which is a time-honored technique with CVS. The second, which I believe was mentioned, is to reduce the number of revisions by obsoleting those that are no longer needed. This is the marginal technique because history is lost, and the nature of the differences may not buy you anything. The third method is to spawn new branches off the head and merge the latest versions of your existing branches onto the new branches, then convert your process to use the new branches instead. This must be repeated periodically to keep a cap on response time. On Feb 9, 2005, at 7:37 AM, [EMAIL PROTECTED] wrote: Hi folks, I've searched the net and mail archives for some help or workaround to my problem, but most binary issues tend to deal with the impossibility of diff/merge or whether very large files can be stuffed into CVS. I and the rest of us out here work with Oracle Forms and that means binary source code. At first I was very suspicious of moving to CVS because we were having binary source code, but as it turns out I and everyone else have become extremely happy with CVS. We can't merge, granted, but with our external diff application we reap enormous benefits from using CVS. Even branching is manageable. But here's the problem, especially with our largest 3,5 MB file that's been committed approx. 70 times. When doing a cvs update -r HEAD filename things work real fast (5 seconds). But if we do a cvs update -r branch version filename performance drops from 5 seconds to a minute and a half. I can imagine something ugly happening with the filename,v file on the cvs server which is 200 MB large. The performance isn't killing us right now, but in maybe 6 months to a year, who knows how bad it may have gotten? So the question is if there are any administrative tools one can use to compress/rationalize/index the file so branch access becomes faster? Is there a way to permanently erase stuff older than 6 months? And if not: opinions about my ideas below would be great? My ideas so far: MOVE variant: I wouldn't _like_ to lose the history of the application, but it might be acceptable if performance degrades too much. I figure I could move the filename,v file on the cvsroot repository (to a backup folder), then delete from client and add a fresh one and the 1-2 active branches - but can any history be kept if you do this? Will the old history be in the backup folder? MIGRATE: An alternative would be to create a new folder (while keeping the old one) and simply migrate _all_ 85 files to the new folder (grab HEAD, add all in HEAD to new folder, grab endpoints on branches, add all branches as I best can). Regards, Jesper Vad Kristensen Aarhus, Denmark ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs -- Paul Sander | To do two things at once is to do neither [EMAIL PROTECTED] | Publilius Syrus, Roman philosopher, 100 B.C. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Medium sized binaries, lots of commits and performance
On Feb 9, 2005, at 8:53 AM, [EMAIL PROTECTED] wrote: Jesper Vad Kristensen writes: I and the rest of us out here work with Oracle Forms and that means binary source code. Are you sure there isn't a way to store them as text or to convert them to text? Source control systems are popular enough that there almost certainly is. Storing them in text form rather than in binary is by far the best solution to your potential problem. Jesper also wrote: We can't merge, granted, but with our external diff application we reap enormous benefits from using CVS. Even branching is manageable. This appears to be a case where adding support for external datatype-specific diff and merge tools would be useful. -- Paul Sander | Lets stick to the new mistakes and get rid of the old [EMAIL PROTECTED] | ones -- William Brown ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: tagging method
Some follow-up questions: - When you do the checkout, do you use the -f or -P options? - When you do a cvs log of a file in B/otherDir, is the tag listed? On Feb 9, 2005, at 10:36 AM, [EMAIL PROTECTED] wrote: Let's try this again Greetings, I am currently maintaining some code in a 2 monolithic cvs repositories. A/3rdparty A/project1 A/project2 B/project3 B/project4 B/otherDir When I started working with these repositories the only builds (asside from developer's private builds) where done by tagging building all sources. As these projects diverge, I have been tagging only dependant modules necessary to build an individual app. E.g. project1 depends on sources in project3 so I apply tags and branchtags like so: cvs rtag -rALLSRC_01 APPLICATION_1_0_0_3 A/3rdparty A/project1 B/project3 I have 2 questions: 1. Is this tagging method acceptable? 2. If so, when I check out thusly: cvs co -rAPPLICATION_1_0_0_3 A B, why do I get some extra directories and sources that where not explicitly tagged (e.g. B/otherDir) -- Paul Sander | Lets stick to the new mistakes and get rid of the old [EMAIL PROTECTED] | ones -- William Brown ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: tagging method
Interesting. Just before invoking cvs tag, can you confirm that B/otherdir is not in your workspace? Does the output of cvs tag give any indication of what it's doing at the time it applies the tag to B/otherdir? --- Forwarded mail from [EMAIL PROTECTED] On Wed, 9 Feb 2005 11:23:52 -0800, Paul Sander [EMAIL PROTECTED] wrote: Some follow-up questions: - When you do the checkout, do you use the -f or -P options? Niether. I do a clean cvs co -rTAG base module Tested with -P, same results as without. - When you do a cvs log of a file in B/otherDir, is the tag listed? The tag is in fact listed for all files in the extra directory. This seems to point towards me having inadvertantly tagged that directory. So I did another test: rm -rf A B cvs co -rOTHER_TAG A/3rdparty A/project1 B/project3 cvs tag NEW_TAG A B rm -rf A B cvs co -rNEW_TAG A B Once again, B/otherdir is there and the log shows it tagged as NEW_TAG... --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cross-directory merge
CVS can't handle it. For each file, you must identify the file/version pairs for the common ancestor and two contributors, get them all into your workspace, invoke diff3 with the proper incantation, and commit the result. --- Forwarded mail from [EMAIL PROTECTED] Lets say I have the following situation ---MYBRANCH / / / --HEAD Where MYBRANCH is the production code (currently unders support) and HEAD is the new development code base. Lets again say I have to reorganise the files (rename and move files and directories -- in particular, do a massive java refactor) on HEAD. Then lets say I have to do a bug fix on MYBRANCH, and merge that bugfix down to HEAD to make sure it's been replicated. How would I go about doing my directory/file moves so that I could still do the merge later. Any suggestions as to how to accomodate this problem (and whether cvs can handle it) would be appreciated. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Renaming (was Re: 'cvs add' client/server semantics)
On Feb 5, 2005, at 12:52 PM, [EMAIL PROTECTED] wrote: [ On Wednesday, February 2, 2005 at 18:23:08 (-0300), Alexandre Augusto Drummond Barroso wrote: ] Subject: RE: Renaming (was Re: 'cvs add' client/server semantics) I agree with you. I think the result from an annotate would be completely different when using a move operation instead of traditional mv-remove-add operation. You are thinking of, or wishing for, something at a higher level than a simple cvs annotate. (and annotate is the wrong word for what you mean, especially in the context of CVS where it has an explicit meaning) The idea behind using a wrapper script to implement cvsmove is that it would create predictable, parsable, log entries. This would make it much more reliable for another _external_ history analysis tool to decipher what was intended when it sees that a file was removed from one location then another file with identical content was added to a new location. Gee, Greg, how much version control capability do you really want to offload from CVS? -- Paul Sander | Lets stick to the new mistakes and get rid of the old [EMAIL PROTECTED] | ones -- William Brown ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: 'cvs add' client/server semantics (was Re: Triggers)
On Feb 5, 2005, at 12:47 PM, [EMAIL PROTECTED] wrote: [ On Thursday, February 3, 2005 at 00:29:31 (-0800), Paul Sander wrote: ] Subject: Re: 'cvs add' client/server semantics (was Re: Triggers) Many shops seem to think that it's reasonable to allow users to commit code only after it has successfully compiled. In fact I happen to agree with that partciular policy and I try to follow it as well as I can even on my private projects. However just because a new file appears doesn't mean it's immediately going to be used in the build -- quite the opposite as it normally won't, at least not with any sane build system I would use. I.e. your argument about not immediately committing new, but probably still empty, files is, still, a complete and total straw man. Please try to think a little about these things. Your answer was the kind of automaton-like regurgitation of a simplistic rule which I would only have expected from a computer following an ill-conceived and overly-strict recipe -- or maybe a manager who doesn't actually know how to do the job himself. :-) Some shops rely heavily on autodiscovery in their build systems, and consider it feature. Some shops don't permit committing dead files to an active source base, either, whether it be because they're brand new or because their APIs have just been disconnected from the rest of the system. Please try to open up to disciplines that you have not directly experienced yourself. And you need to start to acknowledge that these are viable approaches to certain problems, even if they're not the specific ones you would choose. Right or wrong, good or bad, these are real world experiences. Perhaps, but I want the option to ask it if it foresees any problems with my actions. If you don't like it, don't use it. I didn't say you couldn't have such an option -- in fact you already have it, in spades. Okay, let me be more clear: I want the cvs add command to give me the option. There's a reason why it needs to be there, even if you refuse to acknowledge it. There are an almost infinite number of ways for you to ask if a new filename is acceptable and not one of them requires any change of any kind to the core CVS program. And most of them require much more work to work around the absence of the capability in CVS than to implement it directly. Many of those possible ways don't even require software implementations. CVS is not a substitute for management, nor a substitute for developer communication, nor does it have a built-in process model. And these are all good things for it not to have too! I agree that CVS shouldn't have this stuff hard-coded into it. However, it's crucial that it have the necessary hooks to integrate with the tools that perform those functions. This is one of the reasons why I maintain that CVS remains a toy system, suitable for managing toy or immature development efforts. If your project requires strict file naming rules be followed then you need to invent procedures and processes to help meet that requirement but you should not even expect to look to CVS for help here. The very fact that you do suggests you think CVS is, or should be, something that it is not. That said you can in fact still implement technical controls that can mandate a requirement like strict file naming rules, IFF you do it through commitinfo scripting hooks. If that's not sufficient for your needs then CVS is not the right tool for (this part of) your project. After two weeks are arguing, you still don't get that the very best time to check a file's name is at the moment it's created. Sigh. Your loss. -- Paul Sander | To do two things at once is to do neither [EMAIL PROTECTED] | Publilius Syrus, Roman philosopher, 100 B.C. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: 'cvs add' client/server semantics (was Re: Triggers)
On Feb 2, 2005, at 12:53 PM, [EMAIL PROTECTED] wrote: [ On Wednesday, February 2, 2005 at 03:35:48 (-0800), Paul Sander wrote: ] Subject: Re: 'cvs add' client/server semantics (was Re: Triggers) Committing empty files may not be permitted by project policy. Straw man! (and a B.S. policy if I've ever seen one!) Many shops seem to think that it's reasonable to allow users to commit code only after it has successfully compiled. I happen to think it's a bogus policy, too, but then the shops that employ such policies have no appreciation of good change control and they think that this is a method that's good enough. Unfortunately, my experience has been that cussing at it doesn't make it go away. No, I don't really want total control over all client operations. But I would like more opportunities for the server to say no. cvs add (and cvs rm) operations DO NOT EVER CONCERN THE SERVER. Period. Perhaps, but I want the option to ask it if it foresees any problems with my actions. If you don't like it, don't use it. -- Paul Sander | To do two things at once is to do neither [EMAIL PROTECTED] | Publilius Syrus, Roman philosopher, 100 B.C. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
On Feb 1, 2005, at 8:16 AM, [EMAIL PROTECTED] wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 31, 2005, at 9:30 AM, [EMAIL PROTECTED] wrote: That's not to say that we will *always* know at add time that the commit will fail; failures can occur due to problems in their content which are clearly not ready to check at add time. Well, if I understand correctly, your intentionally want to have weaker checks at add-time than at commit-time. Instead, you can do it in the commit-time trigger by skipping some of the tests if the file in question is new one. Oh, so what you're saying is that rather than making CVS differentiate between the two sets of triggers, you want the commitinfo script to do it instead. I suppose that's doable. Exactly! I took too much time to explain this. Should be either my or your fault (or both). But I'll counter with this: Why not combine commitinfo, loginfo, and taginfo the same way? My argument is that add-time triggers differ from commitinfo triggers in the same way that commitinfo triggers differ from those others: They run at different times for different purposes. All the triggers you've mentioned have no common tasks to do. On the other hand, add-time checks you have in mind are subset of commit-time checks you have in mind. The subset is easily achieved by bypassing some of checks. Okay so you understand why it's a bad idea to overload too much functionality. I argue that combining add-time and commit-time triggers is also overloading things too much. There's the established commit-time feature that is being modified so that it now runs twice rather than once. If this were indeed done, then thousands of existing CVS admins are inconvenienced because they must rewrite their existing commitinfo triggers to bypass their current operation at add-time, and plus both the CVS authors and the administrators must work through a change of interface in an existing feature. If you examine the implementation, you'd realize that CVS implements its trigger support pretty much in a generic fashion, basically invoking a function call with different parameters depending on the trigger. So there's really no invention going on when adding a new trigger. And it turns out that overloading an existing one is demonstrably harmful. I would have no objection to add-time-script if there were a separate server operation called add-file-to-the-working-copy, or check-if-file-name-is-ok-for-repository, but AFAIK there is currently no such operations. I consider inventing new server operation just to implement some policy that you have in mind and that could be implemented using existing functionality anyway to be an overkill, sorry. If you go back and read Mark's postings, he mentions that my proposal requires no changes to the client/server protocol, so it's really not inventing a new server operation in a very real sense. It changes the behavior of the server, but if at add-time you invoke the option to avoid contacting the server, then why do you care? You need to get out of the server. The server's not the one we're trying to make happy here. It's the user that matters, and the tools must bend to the users, not the other way around. From an implementation standpoint, there's no difference between the triggers, other than the conditions in which they fire and the files in which they're configured. Thus the argument you make in the above paragraph simply makes no sense. It's you who needs to get out of the server, not me. You propose server changes, not me. If the functionality has nothing to do with the server, then get out of the server indeed. Yes, you do propose server changes: You propose invoking an existing trigger in a second place. I argue that implementing a second one performs the same function that you propose, but in a cleaner way that preserves existing practice. If I do in fact understand you to be recommending that commitinfo be used at add time, then I must disagree. Triggers used at commit time to check the content of files (like Greg's RCS Id trigger, for example) are not appropriate to use at add time. Things like checking that the user has the right to add a file, or checking that the name of the file complies with policy, are legitimate to check at add time. They can also be checked at commit time, and the current proposal does that because the add-time triggers are optional. So the only thing you need to know in the commitinfo is what user is trying to do and decide what checks are required based on this information. If commitinfo currently doesn't have all the required information, maybe it's better to fix it instead of inventing yet another hack in the form of add-time triggers? What you're really proposing is an alternative implementation for add-time triggers. Think about it. It's how it looks from your point of view. From my point of view I propose alternative implementation of the functionality you need without inventing anything new
Benefit of policies (was Re: Triggers)
On Feb 1, 2005, at 12:13 PM, [EMAIL PROTECTED] wrote: [ On Sunday, January 30, 2005 at 16:45:35 (-0800), Paul Sander wrote: ] Subject: Re: Triggers (was Re: CVS diff and unknown files.) It's not so unusual for people who have done SCM for many years on large and varied projects. Well it depends -- you seem to belong to a (hopefully small and dwindling) group of extremely policy centered, control oriented, SCM managers. Not every large shop (still) does things that way. Lots of very large and diverse projects use CVS quite successfully without any policy enforcement at the CVS repository level. They're successful no doubt for some value of success. Are they able to ship products? Of course. Do the products work? Very likely. Can they do it efficiently? With the right people, probably. Can they stand some improvement (i.e. higher quality, faster throughput, fewer resources)? Very likely. Software development and management doesn't have to be hierarchically and strictly controlled in the way you seem to think it should. The tools don't have to get in the way of the users. Change tracking tools like CVS really should only ever track changes, and the only server-side scripting that's needed to do that is the kind that CVS more or less has already: hooks to make flexible site-specific reporting easier to implement. I know people who have worked in shops that achieved CMM levels 4 and 5. Unequivocally, they really liked it. These shops are obviously carefully controlled and monitored, and the metrics feed back into the process to remove the biggest hinderances to producing ambitious high quality products in short amounts of time. The key to this is not necessarily to have control for its own sake, but to remove places where people screw up. In other words, enhance success by removing unsuccessful elements. Or, repeat what works, stop what doesn't. That's the approach I take to making policies. If something proves harmful, make it hard to repeat, or at least make it easy to avoid. If someone has a best practice that has proven successful, use it. Having written policies to encourage the most efficient development is a start. But process automation is needed to keep things on track because people forget what's in the book on their shelf. -- Paul Sander | Lets stick to the new mistakes and get rid of the old [EMAIL PROTECTED] | ones -- William Brown ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Triggers (was Re: CVS diff and unknown files.)
On Feb 1, 2005, at 12:03 PM, [EMAIL PROTECTED] wrote: [ On Saturday, January 29, 2005 at 15:22:34 (-0800), Paul Sander wrote: ] Subject: Re: Triggers (was Re: CVS diff and unknown files.) You don't seem to understand the fact that cvs add and cvs rm are supposed to be exactly the same as vi or any other file modification tool (except they operate on the whole file and all its content at once). What I understand is that they are that way, and that they have always been that way. I might even accept the argument that they're supposed to be that way. What I will not accept is that they *must* be that way, and I argue that there is value if they are changed. You don't seem to understand that your insanely powerful drive to have policy controls over everything is quite contrary to the very design goals of CVS overall. I do not have an insanely powerful drive to have policy controls over everything. I have strong desire to have some control over things that meet one of these two criteria: - By consensus, they offer significant advantage in time and expense. - They are demonstrably harmful, i.e. have been used to cause significant harm in the past. CVS is _NOT_ a complete SCM solution and it's not supposed to try to be one either. Adding triggers won't make it a complete SCM solution. But they would make it easier to integrate it with other tools to create one. That is what I'm after. Wrappers are enablers, not enforcers. By their nature, they cannot be enforcers. Yes, they can be. You need to think a little more outside the box you've built around your ideas. Okay suggest a way to do it that's easier than adding a trigger to CVS. Triggers, on the other hand, are enforcers. Actually that's one thing they cannot be -- at least not at any hard technical controls level. CVS is not a security tool. I'm not asking CVS to be a security tool. I'm asking for more places for it to say no when users attempt things that are not permitted by the project. CVS is not about enforcing policy. CVS is not a complete SCM solution. Obviously not, that's why we're having this argument. CVS is a very simple file versioning tool that is designed to keep as much out of the way of the user as is possible and only do exactly what the user wants, and to do it only when the user wants it done, and to only try to do a very select set of operations on a very select set of object types. NOTHING more. Fine. Give me the hooks I need and I'll make it into what I need it to be. Tell me something. If this were true, why does your commitinfo check for valid RCS ID's? Why don't you periodically run a script to check your sources for them? Because it's easier and infinitely more efficient to have CVS run that script exactly once when it's needed on exactly the files it needs to run it on and never any other time and never on any other files. Yep, that's what I want, too. I just have different actions that I want to perform. Here's another horror story. On another project, we're using a version control system that has a command that does what cvs rm does, but with an instant commit. It also has an option to perform a recursive descent. Why is that a horror story? The whole point of versioning systems is that you can undo your changes. After all you didn't say that the command did what rm -rf /* does when root runs it -- i.e. it didn't make a permanent, irreversible, change that affected everyone. True, but it did make a temporary, reversible change that affected everyone. And it took hundreds of man-hours to recover. TWICE!!! This is not acceptable. The CM guy for that project was concerned about such capability in the hands of the end users, and raised the issue with management about whether or not to make it an admin function. Than he is, or was at that time, a paranoid idiot who doesn't, or didn't, understand the tools and their utility. It took them a day to restore visibility of all of the files, and a week to redo the legitimate deletions that had accumulated. Clearly that tool wasn't very well designed and implemented to do even the very most basic job of change management. Really? In CVS, the corresponding actions are to run cvs add on every file found in the attic, review the tree, and run cvs rm for the files that had been legitimately removed prior to the hiccup. Had we used CVS, we would have been in exactly the same boat. If we'd had the ability to limit the effect of the removal command, we could have either forced the user to rethink what they were doing or at least reduce the amount of work required for recovery. That would have been good. There are many ways we could have limited the effects of the removal that would have not gotten in the user's way, at least to a lesser degree than the amount of work required to recover. We could have: - Disabled the recursive descent option for end users (i.e. have an admin do it). - Limited the depth of the removal. - Limited
Re: 'cvs add' client/server semantics (was Re: Triggers)
the server needs to be upgraded to add the new functionality. Again, to do it right I think it would -- and then there's cvs rm And while we're at it, how about cvs admin... Greg's arguments for not contacting the server on a 'cvs add' would require the semantics of a 'cvs commit' to be extended to allow for new directories to be created Well it depends on what level you're looking at, but no, 'cvs commit' semantics are not really changed -- my complete cvs add revamp already covers this whole issue. Remember directories are not tracked in any way -- they're just placeholders for filenames. They simply come and go as required. If there are files to go in a directory then the directory has to exist, and if there are no files to go in it then it does not exist (though of course files are never really removed in the repository since their history must be preserved, but that's already handled by the prune option (which shouldn't be an option -- it should always happen). So, from an implementation point of view, it would appear that Paul's proposal is easier than Greg's. They're not even really related -- my cvs add proposal simply fixes the long standing problems and bugs to bring it in line with cvs rm from a UI perspective. Paul's proposal is only really about adding server hooks to all client commands. The only reason my proposal pushes Paul's I have to have total centralized control hot-button is because I take away one of his potential points of control -- one he should never have been able to consider as possible in the first place. He spends a lot of time and effort arguing for total centralized control over the client operations, but he lost that argument the day he considered CVS in the first place, except of course he had a taste of CVS before it was split into a clientserver application and he seems to still long for the bad old days of a monolithic single program. No, I don't really want total control over all client operations. But I would like more opportunities for the server to say no. And in the specific case of cvs add it would be useful to warn the user earlier that certain classes of errors have been detected and that he might consider changing directions before it becomes a problem. Sergei is right -- Paul should only give his users dumb terminals and he should require them to login directly to his central development machine so that he can control every keystroke his users make. That's an exaggeration. I really don't want to control every keystroke. I just want to keep them on the path they've agreed to take, because it's easier to stay there than to wander off and find the way back. -- Paul Sander | To do two things at once is to do neither [EMAIL PROTECTED] | Publilius Syrus, Roman philosopher, 100 B.C. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Renaming (was Re: 'cvs add' client/server semantics)
On Feb 1, 2005, at 1:25 PM, [EMAIL PROTECTED] wrote: [ On Monday, January 31, 2005 at 08:05:47 (-0800), Mark D. Baushke wrote: ] Subject: Re: 'cvs add' client/server semantics (was Re: Triggers) If I move 'foo.c' to 'bar.c' the CVS/Entries file is going to be confused. In general, doing lots of bulk renaming and local 'cvs add' and 'cvs rm' operations without contacting the repository could be useful in some situations, but could be very confusing as well. Indeed -- people (CVS users in particular :-) need to stop thinking in terms of rename and go back to the good old fundamental underlying concepts of creation and deletion. There is no such thing as a rename in most facets of computing. In many facets of computing, that's certainly true. I don't know if I would go so far as to say most. There are many places where they want a move but add/delete is an acceptable alternative because it proves to be simpler in specific domains. There are many places where there are alternative algorithms, some of which use move and others use add/delete. Differencing algorithms, for example, have implementations using both methods. The algorithm that the original Unix diff command used was older and didn't use moves, and its successors maintained the same output format. So there are no popular versions of diff on Unix that list moves, only additions and deletions. I maintain that in the version control domain, add/delete are not a suitable equivalent of a rename operation. The reason is because there's more to it than linking together partial logs as Greg claims. There are also issues relating to branch management, like deciding which RCS file version 1.2.1.3 comes from. -- Paul Sander | To do two things at once is to do neither [EMAIL PROTECTED] | Publilius Syrus, Roman philosopher, 100 B.C. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
On Feb 2, 2005, at 5:02 AM, [EMAIL PROTECTED] wrote: Greg A. Woods [EMAIL PROTECTED] writes: [ On , January 31, 2005 at 20:30:21 (+0300), Sergei Organov wrote: ] Subject: Re: CVS diff and unknown files. Don't you wish to even try to understand the suggestion? The suggestion is: invoke *the same triggers* both at 'cvs add' and 'cvs commit' time, -- there is no need for separate triggers. No, using the same scripting hook at both add and commit times would be bad, VERY bad. Sure. But I didn't in fact suggest it. I in fact argue in favor of absence of add-time hooks on the server at all. Let me try to explain, as the exact meaning of the suggestion has been somehow lost in the endless discussion with Paul. What do we exactly mean by add-time here? The time when cvs add client command is invoked, or the time when new file is to be committed to the repository using cvs commit? I think we agree that add-time is the moment that the user invokes the cvs add command. If the latter, that is not the topic of this discussion. If the former, then server should not care/know about cvs add at all, so there is no such thing as add-to-working-copy time from the point of view of server, so there could be no server hooks invoked at this non-existing time, so these non-existing hooks can be neither the same nor different from commit-time hooks. In other words, I believe there should be no cvs add server command at all. My argument has always been that, for certain policies that do not involve evaluating the content of a file (like enforcement of naming conventions) that there is value to having an add-time check. The reason for this is that if certain classes of early actions are botched, it's better to find out sooner than later, because doing so can save the user from a lot of lost work. So while you believe that add-time hooks are folly, there's another half of the community that thinks they're very useful. Sergei, in the SCM world, there are many issues in which half of the community thinks one way, the other half thinks the opposite. This is apparently one of those issues, at least with CVS. There is no winning the argument on either side. All that can be done is to build a solution that satisfies one side without inconveniencing the other side too much. I believe that my proposal does exactly that. To recap: - Create an add-time trigger mechanism that - Has an interface identical to the existing *info files - Registers the add-time triggers in a new file, perhaps named addinfo - On the client side and selected by the user, perform one of the following actions when the user invokes the cvs add command - Record the new file in the Entries file without contacting the server - Contact the server to run the addinfo trigger, recording the new file in the Entries file if the trigger complete successfully - Run the addinfo trigger prior to any commitinfo trigger when the user invokes the cvs commit command The reasons I believe this proposal satisfies all requirements are: - Using addinfo triggers is a decision of individual projects. - Users are not required to change their working habits. - Users and projects that need add-time triggers get them. - For CVS administrators, this is fully backward compatible. - For CVS users, a new option to cvs add appears which either: - contacts the server by default but is defeated forever in one action or on the command line - does not contact the server by default but is enabled forever in one action or on the command line In other words, it has zero impact on those who don't want or need it, but it's available to those who do. What I actually meant in the phrase you've taken out of contents and commented against is: iff somebody decides he needs to perform some checks on the server whenever user adds files to his working copy, he can arrange to invoke cvs -n commit after every cvs add (or as [optional] part of cvs add). This effectively makes *virtual* add-time hooks equal to commit-time hooks without any server-side add-time hooks. The problem is that if you reuse the commit-time hooks in this way, you are overloading that capability in a way that I (and apparently Greg) believe is not appropriate. -- Paul Sander | Lets stick to the new mistakes and get rid of the old [EMAIL PROTECTED] | ones -- William Brown ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
On Feb 1, 2005, at 2:51 AM, [EMAIL PROTECTED] wrote: Paul Sander [EMAIL PROTECTED] writes: Would you post a message stating your point of view, completely, please? Thanks! I need a way to generate 'cvs diff' against read-only repository. To achieve this it's enough to fix 'cvs add' so that it either doesn't contact the repository at all, or just doesn't require write permission to the repository to succeed. As a response to the question, I've got a reference to the discussion about new 'cvs add' implementation, where you, Paul, argue in favor of new implementation of 'cvs add' to contact the repository to run some new scripts you called add-time triggers. I then tried to tell that I'm yet another person here who is against such a thing and tried to suggest another way of achieving your actual goal, -- checking something against repository at add-to-working-copy time using existing commit-time triggers. There are two proposals on the table. The first is Greg Woods' proposal to make cvs add be a purely local operation. The second is mine, which implements add-time triggers that require calling the server but in a way that the user can opt out of them when invoking cvs add. Does that meet your need? -- Paul Sander | Lets stick to the new mistakes and get rid of the old [EMAIL PROTECTED] | ones -- William Brown ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: 'cvs add' client/server semantics (was Re: Triggers)
On Jan 30, 2005, at 10:24 PM, [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sander [EMAIL PROTECTED] writes: Wait a second. The OK for addition, but wrong for commit is exactly the status quo. The cvs add command succeeds, cvs commit fails due to commitinfo. What I'm proposing is bad for addition, bad for commit, where cvs add fails on those occasions when we know at that moment that cvs commit will also fail. That's not to say that we will *always* know at add time that the commit will fail; failures can occur due to problems in their content which are clearly not ready to check at add time. I find that concrete examples are useful... [ Reasonable example involving MyFoo.h vs. myfoo.h naming in a mixed Unix/Windows shop omitted ] Now, I will grant that it is certainly possible for a user to 'fix' their checked out tree to work around this problem. However, it may be desirable to get it right the first time rather than waste time later. However, I am not sure how this argument for an advisory trigger at 'cvs add' time which then becomes a manditory 'enforcement trigger' at commit time would not also be potentially very confusing to the users. I agree that it could be a potential source of confusion for the users. They're confused about the whole concurrent development paradigm, too. Both sources of confusion can be cleared up with the proper training. Also, I'm recommending that add-time triggers be optional, not advisory. Optional means that that they can be turned off. Advisory means that they can be ignored. There are two differences between the two concepts: Advisory triggers must always contact the server to provide their advice, and they never block an operation. Optional triggers contact the server only when they're turned on, and they block additions when they're turned on and fail. I also strongly recommend that, if the cvs add command is used in such a way that the trigger fires and fails, the Entries file not be modified and the exit code should indicate an error condition (not a warning). At present, it is clear from both sides that the 'cvs add' behavior is broken. I have probably missed some of the points, but let me try to summarize: - a new directory that is added with 'cvs add' does not go thru any peremptory enforcement checks at all (a cvs add trigger OR a policy that cvs add is a local-only operation would partially fix this provided that some other trigger addressed the creation of a new directory in the repository). I'm not sure I fully understand what was said in this paragraph, but I'd like to say that I believe that adding directories should also be triggerable events, and that policies enforcing directory additions could be potentially different from policies enforcing file additions. Expanding on Mark's example, a second policy might require that directory names can not contain period (.) characters. To make this happen, the trigger must be aware of the kind of artifact that's being added. - related to this, the 'cvs import' functionality is likewise 'broken' as it currently may stomp on existing tags and could create files and directories that are not acceptable to an administrators policies. There are presently no enforcer triggers that prevent a particular user from doing an import into the repository. This is true, and integrating triggers into import requires a lot of thought. I would suggest as a topic of discussion that import should scan the input tree and run all triggers in advance of the first change of persistent state. But this is a very touchy subject because the vendors that make the drops may in fact make changes to the tree that violate local policy. The CVS admin is then faced with a dilemma: Should the tree be imported as-is for accurate tracking of vendor drops, or should the tree be adjusted according to local policy and potentially breaking the vendor drop? - there are good reasons for both 'cvs add' and 'cvs rm' to be considered as local operations that should not contact the server: a) allows read-only users to generate 'cvs diff -N' output to send to a maintainer I think this is common only when the user has read-only access to the repository, correct? b) lets the local user experiment with re-oranization of the hierarchy of a module. (It is unclear if there would be any easy way to 'rename' files in the local tree and resolve them in a reasonble manner with the cvs server at a later date.) Depends on what you mean by resolve. After mv'ing a directory in a workspace to something new, CVS still maps it to its original location in the repository. If you're thinking about somehow having the rename be reflected in the repository, then you're treading dangerously close to another heated argument. :-) c) allows a user to continue to do useful work even when access to the server
Re: CVS diff and unknown files.
On Jan 30, 2005, at 2:18 AM, [EMAIL PROTECTED] wrote: Todd Denniston [EMAIL PROTECTED] writes: Sergei Organov wrote: Todd Denniston [EMAIL PROTECTED] writes: If cvs -n commit runs the triggers to do your check(see my question above), I have another question: in a remote server setup (i.e., :pserver:, :ext:) which test was failed, the add or the normal commit? With my approach there is no add-to-working-copy-time triggers, adding of a new file is normal commit (the commit time trigger should have a way to check if the file is already in the repository or not). So your question reduces to the following: how client knows what exactly failed? and the answer is through appropriate error message, as usual. Please notice that with separate add-to-working-copy-time triggers the situation at commit time is exactly the same as those triggers must be run at commit time anyway. What's an answer to your question in this case? There is a certain amount beauty in the simplicity in keeping the status quo, which works. :) Unfortunately, it doesn't work, sorry -- that's why I've initiated this thread in the first place. Huh? You know what status quo means, right? It means the way things are. You seem to be arguing both ways. Would you post a message stating your point of view, completely, please? Thanks! There is also beauty in having the options you want, and none that get in other peoples way. For one of these options much more energy must be expended. :) That's why I've tried to suggest a way to implement things that is rather simple. Still it provides an option to check if a new file will be allowed to go into repository. Unfortunately, if checking for compliance is an option, it will never (or at least very rarely) be taken for one of the following reasons: - They think they are already in compliance and don't need to check. - They think they have legitimate cause to break policy. - They're unaware of the policy. - They forget to check. It's possible to have a third party check periodically, as Greg suggests. But that method isn't as effective as automatic enforcement at the moment the violation occurs. -- Paul Sander | To do two things at once is to do neither [EMAIL PROTECTED] | Publilius Syrus, Roman philosopher, 100 B.C. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
On Jan 30, 2005, at 3:28 AM, [EMAIL PROTECTED] wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 28, 2005, at 11:36 AM, [EMAIL PROTECTED] wrote: [...] If you consider my suggestion, there will be no such a beast as add-to-working-copy-time trigger. The commit trigger will notice the file is new and invoke appropriate additional actions (if any). That's all. There is absolutely no need for separate add-to-working-copy-time triggers. Clients still have ability to check if their new files will be accepted by the repository using cvs -n commit. What you suggest is exactly the status quo. The problem is that the status quo fails to meet the needs of part of the CVS community. The reason is because there's an underlying assumption that project policies are voluntary. That assumption is false, and for good reason. It seems that you attempt to turn CVS itself into a project management tool. If that's your actual intention, please say it aloud, and I'll immediately stop all of my previous arguments and replace them with a single one: CVS should not be turned into a project management tool. Project management is not something that can be implemented in a single tool. It encompasses a lot of things ranging from identifying a market all the way to end-of-life support. Accomplishing it well involves a great many things, including planning and scheduling (the part that project management tools do), methodology (including policies, toolsets, and disciplines), and many other things, all of which must integrate and interoperate with each each other successfully. I'm not asking for CVS to be a project management tool in any sense. What I'm asking for is a hook on which to hang other parts of project management. The commitinfo hook already exists, and it's effective at what it does. All I'm asking for is another hook, to be used as the project sees fit. Where I work, our projects run for several years and have several teams come in to do different things over its lifetime. (The company maintains its market responsiveness by running multiple similar projects concurrently, which allows several product releases per year. I won't go into why this is the case, but suffice it to say that it goes as fast as it goes and there's no speeding things up.) Over the lifetime of the project, the number of files under source control swells up well into the 6-figure range. To manage the complexity and to assist the human factors of exploration, we live on certain conventions. We have conventions for directory structure, conventions for types of data that sit in what directories, and dozens of naming conventions for files and directories. Our test suites have many optional features, and different sets of these optional features are required to run in different directories. Violations of the conventions can cause the test suites to run incorrectly. Because no errors are reported, there may be significant delays until the problems are detected. At that time, the cost to repair the defects may be huge, in the 6-figure range. And this doesn't consider the humiliation felt by the poor guy who made the typo while creating the file. IMHO in your case you shouldn't teach users to use CVS at all, -- you should teach them to use your project management tool, so they won't be aware about cvs add at all. If CVS lacks some functionality and that prevents you from building your tools on top of it, please provide some evidence this functionality is a must to achieve what you need. Okay, CVS lacks an ability for cvs add to invoke a script, in the same manner that cvs commit invokes scripts via the commitinfo file, to validate the addition. Therein lies the justification for add-time policy checking. Yes, commit-time checking will still save many thousands of dollars in repairs, but add-time policy checking saves even more. CVS doesn't prevent you from implementing whatever add-time checks you need on the client side. If you think otherwise, please provide an evidence. See above. And true, the projects I describe don't use CVS. But in the past at another company that produced similar products using similar processes, we did in fact use CVS, and we faced the same problems. Most of the people in this forum don't seem to face these kinds of problems to this extent, but anyone who does cross-platform development faces similar problems. These problems are an issue of a good project management tool, not CVS. If you don't have suitable project management tools, it's not CVS problem. It would be CVS problem if it didn't provide enough functionality to allow you to build a suitable project management tool on top of it. It doesn't see above. If cvs -n commit runs the triggers to do your check(see my question above), I have another question: in a remote server setup (i.e., :pserver:, :ext:) which test was failed, the add or the normal commit? With my approach there is no add-to-working-copy-time triggers, adding of a new file is normal
Re: CVS diff and unknown files.
On Jan 30, 2005, at 3:42 AM, [EMAIL PROTECTED] wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 28, 2005, at 9:34 AM, [EMAIL PROTECTED] wrote: Sergei Organov wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote: If cvs add will only warn about the problems, -- that's OK with me as a user. Actually, the way I see the situation is it only prevents the add if you have requested the check with -c, if you have not used -c there is no connection to the server and therefor can be no warning or prevention. Actually, to err on the side of safety (which I define as policy enforcement in this case), I recommend that the trigger be enabled by default. The power users can turn it off in their .cvsrc files. I have two reasons for this: The first is that they're the ones who express an opinion and there are fewer of them than there are ordinary users, and the second is that they're the ones most capable of making the change in their own environments. The fundamental problem with your approach is that policy enforcement at the client side is not CVS business. You still didn't explain what's wrong with writing your own scripts on top of CVS to enforce whatever policies you wish on the client side, or, if there is nothing wrong about it, how CVS prevents you from enforcing whatever policies you need on the client side. I agree that there's a limit beyond which CVS should not interfere with the user. The user should, for example, be able to use whatever tools in his workspace as he deems necessary, provided it interoperates with rest of the methodology. Creating and deleting files in the workspace is clearly within the user's purview. However, as soon as the user declares an intent to store a file in the repository, he begins to subject himself to the policies of the project. Sooner or later, before he commits his work, he must comply. Granted the time between cvs add and cvs commit is kind of a grey area, and the scope of add-time policy enforcement is pretty limited. (Access control and naming conventions are pretty much all you can do at that point. Arguing that it's reasonable to check the content of a file (for example) at that point is bogus, in my opinion.) But for those things that are reasonable to check, adding to CVS the ability to check them is totally reasonable. On this point I seem to be getting overruled because most of the members of this group are power users and don't adequately represent the end user community. It seems you miss the point, at least my point. I in fact don't care much if -c is default or not provided CVS still allows me to add files to the working copy offline. I care about it as a (hopefully rather experienced) programmer that immediately sees fundamental deficiencies in the underlying design. Not being CVS designer I don't in fact care about it that much either, -- just tried to explain an alternative design that I believe is better. The add-time trigger proposal accommodates your requirement to have cvs add complete successfully when working offline. In your case, detection violations of add-time policy would be deferred until commit time, and you might be forced into some significant rework. You're clearly willing to take that risk and pay the cost, and that's your prerogative. In my opinion, having the user run cvs -n commit right after cvs add is not at all a better solution to this particular problem. -- Paul Sander | To do two things at once is to do neither [EMAIL PROTECTED] | Publilius Syrus, Roman philosopher, 100 B.C. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
On Jan 30, 2005, at 6:40 AM, [EMAIL PROTECTED] wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 28, 2005, at 8:50 AM, [EMAIL PROTECTED] wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote: [...] Just to understand your point better, do you propose 'cvs add -c new_file' and 'cvs ci new_file' run exactly the same set of triggers? Different sets? I think the consensus in the last iteration of the topic was that, if add-time triggers were implemented, they would run as a client-side option at add-time and and be obligatory at commit time, preceding commit-time triggers. Doubling the overhead was the only way we came up with at the time that guaranteed that the add-time triggers fired at least once prior to the first commit of a new file. Well, so the answer to my question is the two trigger sets are different. But it in turn means that it could be the case that I won't be able to 'cvs ci new_file' even though 'cvs add -c new_file' just said the file is OK to be added. IMHO that's a mess. And I believe this mess is direct consequence of poor design choices you are advocating, sorry. A commitinfo trigger can always refuse a file for which cvs add completed successfully. There's nothing new here. If you don't like that, then don't use commitinfo. In my design the triggers are the same, so there is no such problem. Either the file is OK for repository or not, -- simple and clear. The less problems, -- the better. Okay, don't use the add-time triggers in your shop. No one is forcing you to. In your design there is OK for addition, but wrong for commit that IMHO is a nonsense. I believe such a design is seriously flawed, sorry. Wait a second. The OK for addition, but wrong for commit is exactly the status quo. The cvs add command succeeds, cvs commit fails due to commitinfo. What I'm proposing is bad for addition, bad for commit, where cvs add fails on those occasions when we know at that moment that cvs commit will also fail. That's not to say that we will *always* know at add time that the commit will fail; failures can occur due to problems in their content which are clearly not ready to check at add time. What's new is that we can cause cvs add to fail under certain conditions that we know in advance will cause commitinfo to refuse a file. To make sure that the condition is checked, we do it a second time before commitinfo, because some users insist on defeating it the first time. What functionality is lacking? cvs -n ci allows you to do it. All you require is cvs add to *enforce* the checks. I have two levels of objection here: 1. Enforcement by cvs add of the checks doesn't require introduction of separate add triggers as usual commit triggers could do the job as well. My argument is that it does not in fact do the job as well. I've given a number of reasons why in earlier messages. 2. Enforcement by cvs add of the checks is wrong idea by itself as CVS is not a project management tool and should not be. If your project indeed requires such things, let users execute your wrappers instead of direct CVS commands. Wrappers are not capable of enforcing policy by their nature. Triggers are. I've explained why this is so, also. Another point that I would like to make, however, is that CVS can become more feature-rich, support multiple policies, and have a simpler user interface (in most use cases, at least) all at the same time. The problem is that most of us here are too close to the implementation to take a fresh view of the problem. In the core CVS program the cvs add and cvs remove operations must be fixed to be equivalent to vi file.c -- i.e. operations which _ONLY_ affect the local working directory and which _NEVER_ contact the server. See above. If there are no add-time triggers, then I can live with what you say. On the other hand, some shops REQUIRE add-time triggers, and if add-time triggers are used then contacting the server is REQUIRED to make them run. Sorry, add-time with respect to what? Add-time w.r.t. to working copy is entirely different from the add-time w.r.t. repository. Do you realize currently there is no command but 'cvs ci' meaning add this file to the repository? Add time w.r.t. repository currently happens when you 'cvs commit' the new file. Do you propose to change this? What I mean by add-time is the moment in which the user invokes the cvs add command. The canonical example of such a trigger is one that enforces naming conventions, but there are other reasons to control what the user can add. (Some shops don't want users creating directories, for example, and require the CM team to do it for them.) So, provided that cvs add adds the file to the working copy, your definition means add-time to working copy. Requiring server triggers to be run at add-time to working copy seems rather strange design choice in my opinion. Can you suggest another way to enforce add-time policy in a way
Re: Triggers (was Re: CVS diff and unknown files.)
On Jan 30, 2005, at 7:09 AM, [EMAIL PROTECTED] wrote: Paul, your vision of the software world, including client/server, wrappers, triggers, scripts, libraries, security, etc. seems to be so unusual that it makes it very difficult to discuss these things with you. It seems you leave in an entirely different world and therefore need entirely different tools. It's not so unusual for people who have done SCM for many years on large and varied projects. As a suggestion, don't give computers to the users, -- only dumb terminals connected to a server where all the policies are enforced the way you like. I mean it, really, that seems to be the only perfect solution to all of your problems. Better yet, whatever the users do, the result should be exactly the same, otherwise some monkey will find a way to misuse the tools and will waste a few days of his precious time trying to recover. There are technical solutions to most of the problems I've encountered so far, certainly all of the ones I've ever brought up in this forum. Hobbling the users for my benefit isn't the answer in the long term. Sorry for the sarcasm above, -- I'm really sorry you need to live in such a world and I really don't see how CVS can help you. As critical as I am about CVS, I really have only 3 or 4 really hot buttons about it. Triggers happen to be one of them. :-) -- Paul Sander | Lets stick to the new mistakes and get rid of the old [EMAIL PROTECTED] | ones -- William Brown ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
On Jan 28, 2005, at 8:50 AM, [EMAIL PROTECTED] wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote: [...] Just to understand your point better, do you propose 'cvs add -c new_file' and 'cvs ci new_file' run exactly the same set of triggers? Different sets? I think the consensus in the last iteration of the topic was that, if add-time triggers were implemented, they would run as a client-side option at add-time and and be obligatory at commit time, preceding commit-time triggers. Doubling the overhead was the only way we came up with at the time that guaranteed that the add-time triggers fired at least once prior to the first commit of a new file. Well, so the answer to my question is the two trigger sets are different. But it in turn means that it could be the case that I won't be able to 'cvs ci new_file' even though 'cvs add -c new_file' just said the file is OK to be added. IMHO that's a mess. And I believe this mess is direct consequence of poor design choices you are advocating, sorry. A commitinfo trigger can always refuse a file for which cvs add completed successfully. There's nothing new here. If you don't like that, then don't use commitinfo. What's new is that we can cause cvs add to fail under certain conditions that we know in advance will cause commitinfo to refuse a file. To make sure that the condition is checked, we do it a second time before commitinfo, because some users insist on defeating it the first time. Another point that I would like to make, however, is that CVS can become more feature-rich, support multiple policies, and have a simpler user interface (in most use cases, at least) all at the same time. The problem is that most of us here are too close to the implementation to take a fresh view of the problem. In the core CVS program the cvs add and cvs remove operations must be fixed to be equivalent to vi file.c -- i.e. operations which _ONLY_ affect the local working directory and which _NEVER_ contact the server. See above. If there are no add-time triggers, then I can live with what you say. On the other hand, some shops REQUIRE add-time triggers, and if add-time triggers are used then contacting the server is REQUIRED to make them run. Sorry, add-time with respect to what? Add-time w.r.t. to working copy is entirely different from the add-time w.r.t. repository. Do you realize currently there is no command but 'cvs ci' meaning add this file to the repository? Add time w.r.t. repository currently happens when you 'cvs commit' the new file. Do you propose to change this? What I mean by add-time is the moment in which the user invokes the cvs add command. The canonical example of such a trigger is one that enforces naming conventions, but there are other reasons to control what the user can add. (Some shops don't want users creating directories, for example, and require the CM team to do it for them.) So, provided that cvs add adds the file to the working copy, your definition means add-time to working copy. Requiring server triggers to be run at add-time to working copy seems rather strange design choice in my opinion. Can you suggest another way to enforce add-time policy in a way that's centrally controlled by the CVS admin? When cvs add runs, I don't care whether or not the CVS server modifies the repository. Some people seem to think that running cvs add while disconnected is a useful thing to do. (I take the attitude that client/server applications shouldn't be expected to run without a working network, so I'd never run any CVS command when I was unable to connect to the server.) Very strange attitude. And a very unusual definition of expectations associated with client/server applications. Having this definition, mail client isn't supposed to let you do anything with the mail on your computer without a working network?! I rely heavily on IMAP and SMTP for mail transport. At work, my mail client lives on an NFS server. So no, I don't expect mail to work when the network is down. BTW, the definition of client/server implies the presence of a network for communication between the two parts, without which the application fails. The other method is usually called monolithic, in which the application is self-contained. CVS works both ways, but most of us prefer a remote repository, hence the client/server implementation. However, since triggers enforce policy and must not be defeatable, e.g. by changing one's path or bypassing a wrapper or hacking the client machine, they're best implemented as a server feature. It's for that reason, assuming add-time triggers are implemented, they require a connection to the server. The add-time triggers you are advocating would then create an unfortunate precedent of preventing user from modifying his working copy at a will of CVS repository administrator! PLEASE, DON'T DO IT TO CVS! Sorry for shouting. Fortunately, as triggers are run on the server
Re: CVS diff and unknown files.
On Jan 28, 2005, at 9:34 AM, [EMAIL PROTECTED] wrote: Sergei Organov wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote: If cvs add will only warn about the problems, -- that's OK with me as a user. Actually, the way I see the situation is it only prevents the add if you have requested the check with -c, if you have not used -c there is no connection to the server and therefor can be no warning or prevention. Actually, to err on the side of safety (which I define as policy enforcement in this case), I recommend that the trigger be enabled by default. The power users can turn it off in their .cvsrc files. I have two reasons for this: The first is that they're the ones who express an opinion and there are fewer of them than there are ordinary users, and the second is that they're the ones most capable of making the change in their own environments. This opinion hasn't been clear in all of my posts, but this is how I really think it should work. On this point I seem to be getting overruled because most of the members of this group are power users and don't adequately represent the end user community. -- Paul Sander | To do two things at once is to do neither [EMAIL PROTECTED] | Publilius Syrus, Roman philosopher, 100 B.C. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
On Jan 28, 2005, at 11:36 AM, [EMAIL PROTECTED] wrote: Todd Denniston [EMAIL PROTECTED] writes: Sergei Organov wrote: Paul Sander [EMAIL PROTECTED] writes: On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote: [...] Just to understand your point better, do you propose 'cvs add -c new_file' and 'cvs ci new_file' run exactly the same set of triggers? Different sets? I think the consensus in the last iteration of the topic was that, if add-time triggers were implemented, they would run as a client-side option at add-time and and be obligatory at commit time, preceding commit-time triggers. Doubling the overhead was the only way we came up with at the time that guaranteed that the add-time triggers fired at least once prior to the first commit of a new file. Well, so the answer to my question is the two trigger sets are different. But it in turn means that it could be the case that I won't be able to 'cvs ci new_file' even though 'cvs add -c new_file' just said the file is OK to be added. IMHO that's a mess. And I believe this mess is direct consequence of poor design choices you are advocating, sorry. Careful, Last discussion time it was indicated that if add triggers were to be added, then for them to be useful they would have to run at add time (when the flag requesting them was passed) AND more importantly at commit time, so commit on the server would if it had never seen the file before run the add trigger and then the normal commit trigger. So as long as the add trigger (script) had not changed between 'cvs add -c' (IIRC that was the flag) and commit time and the trigger allowed the add, then the server would at commit time run the add trigger, get a pass run any commit triggers, get a pass if appropriate. So in adding the add trigger functionality, the person patching CVS would have to recognize the signals in the code indicating new file/directory at commit, and connect the hook there too. If you consider my suggestion, there will be no such a beast as add-to-working-copy-time trigger. The commit trigger will notice the file is new and invoke appropriate additional actions (if any). That's all. There is absolutely no need for separate add-to-working-copy-time triggers. Clients still have ability to check if their new files will be accepted by the repository using cvs -n commit. What you suggest is exactly the status quo. The problem is that the status quo fails to meet the needs of part of the CVS community. The reason is because there's an underlying assumption that project policies are voluntary. That assumption is false, and for good reason. Where I work, our projects run for several years and have several teams come in to do different things over its lifetime. (The company maintains its market responsiveness by running multiple similar projects concurrently, which allows several product releases per year. I won't go into why this is the case, but suffice it to say that it goes as fast as it goes and there's no speeding things up.) Over the lifetime of the project, the number of files under source control swells up well into the 6-figure range. To manage the complexity and to assist the human factors of exploration, we live on certain conventions. We have conventions for directory structure, conventions for types of data that sit in what directories, and dozens of naming conventions for files and directories. Our test suites have many optional features, and different sets of these optional features are required to run in different directories. Violations of the conventions can cause the test suites to run incorrectly. Because no errors are reported, there may be significant delays until the problems are detected. At that time, the cost to repair the defects may be huge, in the 6-figure range. And this doesn't consider the humiliation felt by the poor guy who made the typo while creating the file. Therein lies the justification for add-time policy checking. Yes, commit-time checking will still save many thousands of dollars in repairs, but add-time policy checking saves even more. And true, the projects I describe don't use CVS. But in the past at another company that produced similar products using similar processes, we did in fact use CVS, and we faced the same problems. Most of the people in this forum don't seem to face these kinds of problems to this extent, but anyone who does cross-platform development faces similar problems. If cvs -n commit runs the triggers to do your check(see my question above), I have another question: in a remote server setup (i.e., :pserver:, :ext:) which test was failed, the add or the normal commit? With my approach there is no add-to-working-copy-time triggers, adding of a new file is normal commit (the commit time trigger should have a way to check if the file is already in the repository or not). So your question reduces to the following: how client knows what exactly failed? and the answer
Re: Triggers (was Re: CVS diff and unknown files.)
On Jan 28, 2005, at 3:55 PM, [EMAIL PROTECTED] wrote: [ On Friday, January 28, 2005 at 03:26:05 (-0800), Paul Sander wrote: ] Subject: Triggers (was Re: CVS diff and unknown files.) Sigh. Just because you haven't found a use for add-time triggers within the scope of your blinders, doesn't mean that no one has. You don't seem to understand. A new file, from the repository's point of view, thus from any repository policy point of view, does not exist until commit time. The existing commitinfo hooks are more than adequate enough to enforce any repository policy on the new file, be it by name, or by content. (my own commitinfo scripts check that the new file has a proper RCS Id, for example) I understand perfectly what you're saying and why. But you fail to understand the problem. I'm not talking about anything from the repository point of view; my arguments are from the user's and project manager's point of view. Using naming conventions as an example, it's true that at the point the project ships, it doesn't matter from a quality for feature perspective when a defect was found and fixed, as long as the policy is checked sometime before the release. What I'm talking about is something else: The cost to fix defects. Once again, history has shown that defects found early are easier, faster, and cheaper to fix than defects that are found late. If someone creates a new file and spends a day integrating it into the project only to have it rejected by a commit due to a naming policy violation, then he gets to spend another day fixing the mistake. This is an unnecessary effort if only the developer had found out in the morning that the name of his file was bad rather than in the evening. Also, wrappers are not always the answer. Wrappers are always the answer when you want to do something policy related in the working directory. THEY MUST BE. The core CVS program, by design, does not involve itself in policy matters affecting the working directories. The core CVS program is not a complete SCM platform. Wrappers are enablers, not enforcers. By their nature, they cannot be enforcers. You can automate some process using some script, and you can even mandate its use. But you can't enforce its use because as long as there's something more primitive available the user can drop down and use that instead. Triggers, on the other hand, are enforcers. They block higher-level functions when their programmed preconditions aren't met, and they force actions when their programmed preconditions are met. Wrappers are simply incapable of this. - Wrappers can be subverted by the users, sometimes accidentally, sometimes deliberately. If your users are so lazy, ill informed, or antagonistic of their fellow workers, that your shop worries about users subverting wrapper programs, even accidentally, then CVS is _NOT_ the right tool for your shop. Tell me something. If this were true, why does your commitinfo check for valid RCS ID's? Why don't you periodically run a script to check your sources for them? - Some users must be kept away from certain features. If your users are so lazy, ill informed, or antagonistic of their fellow workers, that your shop worries about users accessing certain features, even accidentally, then CVS is _NOT_ the right tool for your shop. Here's another horror story. On another project, we're using a version control system that has a command that does what cvs rm does, but with an instant commit. It also has an option to perform a recursive descent. (Those who believe that remove/add of entire directory structures is a reasonable implementation of the ability to rename a directory can understand the need for this.) The CM guy for that project was concerned about such capability in the hands of the end users, and raised the issue with management about whether or not to make it an admin function. Every end user of that tool undergoes 2-3 hours of training and is given documentation. They also undergo another 1-2 hours to learn how the tool is tightly integrated with one of our mission critical tools. There are also on-site mentors and online support for the tool. It was on this basis that senior team leads and management crushed the CM guy mercilessly, claiming that no one would possibly be so irresponsible as to use that command in a damaging way. Within two weeks of that argument, someone used that command at the very top of their source tree. (This person reported directly to the guy who made the responsibility argument.) It took them a day to restore visibility of all of the files, and a week to redo the legitimate deletions that had accumulated. Within a week after completing the recovery, someone else used that command again, at the very top of their source tree. CVS suffers the same vulnerability. Forgive me for thinking your argument is bogus, because experience proves otherwise. - Access to certain features must
Re: CVS diff and unknown files.
On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote: Paul Sander [EMAIL PROTECTED] writes: [...] What register adds in the repo nonsense are you talking about? The proposal I made simply requires a contact with the server to run the add-time triggers; it does NOT require add-time modifications of the repository by the CVS server itself. If the triggers drop turds in the repository, then that's a different matter. Also remember that my proposal includes a way to shut off the add-time triggers as a client configuration, deferring them to commit time to accommodate users like you. Just to understand your point better, do you propose 'cvs add -c new_file' and 'cvs ci new_file' run exactly the same set of triggers? Different sets? I think the consensus in the last iteration of the topic was that, if add-time triggers were implemented, they would run as a client-side option at add-time and and be obligatory at commit time, preceding commit-time triggers. Doubling the overhead was the only way we came up with at the time that guaranteed that the add-time triggers fired at least once prior to the first commit of a new file. Another point that I would like to make, however, is that CVS can become more feature-rich, support multiple policies, and have a simpler user interface (in most use cases, at least) all at the same time. The problem is that most of us here are too close to the implementation to take a fresh view of the problem. In the core CVS program the cvs add and cvs remove operations must be fixed to be equivalent to vi file.c -- i.e. operations which _ONLY_ affect the local working directory and which _NEVER_ contact the server. See above. If there are no add-time triggers, then I can live with what you say. On the other hand, some shops REQUIRE add-time triggers, and if add-time triggers are used then contacting the server is REQUIRED to make them run. Sorry, add-time with respect to what? Add-time w.r.t. to working copy is entirely different from the add-time w.r.t. repository. Do you realize currently there is no command but 'cvs ci' meaning add this file to the repository? Add time w.r.t. repository currently happens when you 'cvs commit' the new file. Do you propose to change this? What I mean by add-time is the moment in which the user invokes the cvs add command. The canonical example of such a trigger is one that enforces naming conventions, but there are other reasons to control what the user can add. (Some shops don't want users creating directories, for example, and require the CM team to do it for them.) When cvs add runs, I don't care whether or not the CVS server modifies the repository. Some people seem to think that running cvs add while disconnected is a useful thing to do. (I take the attitude that client/server applications shouldn't be expected to run without a working network, so I'd never run any CVS command when I was unable to connect to the server.) However, since triggers enforce policy and must not be defeatable, e.g. by changing one's path or bypassing a wrapper or hacking the client machine, they're best implemented as a server feature. It's for that reason, assuming add-time triggers are implemented, they require a connection to the server. In fact the semantics of proposed 'cvs add -c' is: add this file to the working copy and check if the repository will allow me to commit this new file if I decide to. In this semantic only the latter part has anything to do with the repository, and it is commit, not add, that's why I suggested 'cvs commit' would be more logical place to check for such things. Certain conditions that will allow me to commit this new file if I decide to can be checked at the time the user invokes the cvs add command. The rationale is that if a failure condition can be detected at add-time then any conditions deriving from those creating the failure condition can be halted, thus avoiding costly recovery action at the time when the first commit actually fails. For example, suppose a mixed Windows/Unix shop requires all files to have upper-case 8.3 file names. A new programmer splits a header file and creates a new foo.h. He adds the file, then proceeds to modify all of the source files to include the new foo.h. Then he updates all of the dependencies in his makefiles. He builds and tests on Unix. He types cvs commit, types a very detailed log of his actions, and finally punches the screen. This person might have saved a day's work, his equipment, and his knuckles if only cvs add had said Sorry, this new file violates our naming policy, try renaming it to FOO.H instead. To get your semantics, it seems you need a new operation with the semantics add the file to the working copy and to the repository, but don't give it to anybody on 'cvs update' yet, until I latter commit the addition. Do you propose exactly this? How could it be done without write access to the repository? The semantics I want
Triggers (was Re: CVS diff and unknown files.)
On Jan 27, 2005, at 12:36 PM, [EMAIL PROTECTED] wrote: [ On Wednesday, January 26, 2005 at 21:05:46 (-0800), Paul Sander wrote: ] Subject: Re: CVS diff and unknown files. See above. If there are no add-time triggers, then I can live with what you say. On the other hand, some shops REQUIRE add-time triggers, and if add-time triggers are used then contacting the server is REQUIRED to make them run. I had hoped that this was clear in the last go-round, but apparently not. Developers who think they require add-time triggers need their heads examined, but if they really think they want to implement them then they have all the power of any programming language they desire to do so in a pogram that they build over and above and outside the core CVS program. Sigh. Just because you haven't found a use for add-time triggers within the scope of your blinders, doesn't mean that no one has. Also, wrappers are not always the answer. Sure, it's possible to duplicate the CVS command line and invokes whatever tools enforce policy for the given shop. The thing is, it's a huge duplication of effort when many shops do it, plus the wrappers must contact the server to insure uniform enforcement. We already have code that does that, and it's called cvs. It's faster, cheaper, easier, and more robust to add it to CVS. Agreed. But the tool must be sufficiently flexible to allow robust implementations of policies. Sometimes triggers are the right way (and wrapper scripts are not), and we've identified one area here where CVS is not sufficiently flexible. That's pure and utter bullshit. These so poortly named triggers in CVS now were a poor idea from the start which have been misperceived by folks such as yourself (and no doubt your blathering on about your misperceptions has only spread the problem further) and they've been rather poorly implemented to boot. I agree that triggers as implemented by CVS are poor. They're better than they once were, but they're still poor. That doesn't mean they're not needed or shouldn't be used (or fixed). If you think you want policy control over working directories then either you're using the wrong tool for the job, or you need to think more like a true toolsmith and build your policy enforcement tools over and above and outside the core CVS program where they belong. Are you arguing here that I should not be using triggers, or that I should not be using CVS? If the former, then Greg, the ignorance shown by that statement utterly astonishes. My current employment has me implementing process automation and policy enforcement every day. One of my current projects is to design an engineering change order (ECO) process and the necessary tools to implement it. This is the third such process that I have done (for different projects) in the past two years. We don't use CVS for these projects, but rather a home-grown system. Until recently it had no triggers, and even now their implementation is incomplete. In other words, we face the same limitations with this system as we would have with CVS. People (other than myself, working on other projects) demanded that triggers be added to this version control system for the following reasons, which are valid: - The command given by the user doesn't always have enough information for a wrapper to determine all of the artifacts affected by the trigger. Some processing by the version control system is required before refinements take over. - Wrappers can be subverted by the users, sometimes accidentally, sometimes deliberately. - Some users must be kept away from certain features. - Access to certain features must be restricted conditionally upon the user's specific task. - The runtime cost of certain actions is much cheaper when invoked at a level below the command line. - In client/server environments, certain actions must be performed in the context of the server, not in the context of the user. The security model is such that access to the server is given only to certain trusted applications. - Wrappers can only add functionality. They cannot remove or limit existing functionality. - The actions of wrappers cannot be incorporated into the back-end transactions implemented by the version control primitives. - Wrappers cannot utilize or control primitive operations at a lower level than the command line. Now I will give an example that will absolutely horrify you: We have actually identified cases where our counterparts of cvs checkout and cvs update must be restricted in ways that don't involve classical access control. This directly counters your assertion that policies don't reign over individuals' workspaces. The requirements are: - There is a notion of development phase and frozen phase. - Different branches of the project can be in different phases. - During the development phase, all users have access to all versions of all files. - During the frozen phase: - Users who work
Re: CVS diff and unknown files.
if the above two issues are going to be fixed as a side effect of the proposed 'cvs add' implementation as well. I think the first error should only be generated if the user provided '-c' to the 'tag' command. As for the second case, I think that without '-c' cvs should tag the file (either silently or issuing a warning), and with '-c' it should abort the whole operation. I don't believe that these issues have been considered as part of either cvs add proposal. -- Paul Sander | To do two things at once is to do neither [EMAIL PROTECTED] | Publilius Syrus, Roman philosopher, 100 B.C. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
On Jan 26, 2005, at 11:06 AM, [EMAIL PROTECTED] wrote: [ On Wednesday, January 26, 2005 at 01:01:55 (-0800), Paul Sander wrote: ] Subject: Re: CVS diff and unknown files. You're falling into the same trap that Greg does, which is to think that the way CVS works today is the way that it simply must work (except when he has an idea to make it better for himself). I agree that your use case points out another ugly wart in the way that CVS was designed and implemented. Well since I believe the design to be correct and the best possible for the goals and requirements, it's certinaly not an ugly wart. Okay, so we're in violent agreement on that small point! :-) What would be ugly would be some all-knowing big-brother implementation that forced policy on everyone despite the fact that everyone's needs differ. (and I'm talking of course about multiple groups each with their own repositories, not multiple individuals using the same repo) Agreed. If you want these kinds of policies then you can trivially implement them over and above the core cvs program using wrapper programs and/or scripts. Even your stupid register adds in the repo nonsense can be easily implemented by wrapper programs and a tiny registry on the server. What register adds in the repo nonsense are you talking about? The proposal I made simply requires a contact with the server to run the add-time triggers; it does NOT require add-time modifications of the repository by the CVS server itself. If the triggers drop turds in the repository, then that's a different matter. Also remember that my proposal includes a way to shut off the add-time triggers as a client configuration, deferring them to commit time to accommodate users like you. Another point that I would like to make, however, is that CVS can become more feature-rich, support multiple policies, and have a simpler user interface (in most use cases, at least) all at the same time. The problem is that most of us here are too close to the implementation to take a fresh view of the problem. In the core CVS program the cvs add and cvs remove operations must be fixed to be equivalent to vi file.c -- i.e. operations which _ONLY_ affect the local working directory and which _NEVER_ contact the server. See above. If there are no add-time triggers, then I can live with what you say. On the other hand, some shops REQUIRE add-time triggers, and if add-time triggers are used then contacting the server is REQUIRED to make them run. I had hoped that this was clear in the last go-round, but apparently not. Policy goes above -- it is not hard-coded in the core functionality. Agreed. But the tool must be sufficiently flexible to allow robust implementations of policies. Sometimes triggers are the right way (and wrapper scripts are not), and we've identified one area here where CVS is not sufficiently flexible. On Jan 25, 2005, at 9:29 AM, [EMAIL PROTECTED] wrote: Besides, concerning informing the user about problems ASAP, I find myself using 'cvs add' and 'cvs remove' as *late* as possible (as close to the commit as possible) due to the oddities in CVS behavior described below. Consider the following use-case where the intent of tagging is to mark the repository state just before committing of a set of changes that includes adding and/or removing of some files: $ cd working_copy $ echo a a $ cvs add a cvs server: scheduling file `a' for addition cvs server: use 'cvs commit' to add this file permanently [... time passes ... and now I'm ready to commit...] $ cvs update ... $ cvs tag -F before-my-changes cvs server: nothing known about a cvs [server aborted]: correct the above errors first! Oops! Need to remove file back to be able to tag the repository! Doesn't error nothing known about a look funny by the way? Shouldn't 'cvs update' show N meaning nothing known instead of A as the status of the file then :) No, CVS shouldn't say anything about the unknown file. The tag is being applied to the base revisions of the files in the working directory. A newly added, but uncommitted, file is simply like any other changed file in the working directory and the '-F' should ignore it just as it ignores the changes to files that are already in the repository. I.e. that is a bug, pure and simple. But consider this: All I want to do is tag my files before I commit them, and don't concern me with the detail. Okay, which versions do you want tagged, the ones that appear in your workspace when you did the update, or the ones that will appear in the repository when you commit? That's a nonsensical question. Tags can only be applied to revisions that are already in the repository. Tags applied with cvs tag always begin with the base revisions that the working directory was created with. Remember, I take a user-centric view of the world when I discuss CVS. It's frequently said to users that tags apply to the versions in your workspace when cvs tag is used. But after
Re: CVS diff and unknown files.
On Jan 24, 2005, at 6:20 AM, [EMAIL PROTECTED] wrote: Todd Denniston [EMAIL PROTECTED] writes: [...] $ echo dummy dummy.txt $ cvs add -m dummy.txt cvs [server aborted]: add requires write access to the repository Until the Fix that Greg described late last year is put in, you can (I think) trick cvs at least for files. ***begin cvs_trick_add #! /bin/bash echo /$1/0/dummy timestamp// CVS/Entries echo cvs trick added $1 to the Entries file. ***end cvs_trick_add cvs_trick_add dummy.txt Thanks a lot for the trick, Todd! Though I usually try to avoid temptation to edit CVS/ files manually, it seems that in this case it's indeed easier than replicating of the whole project into another directory and using regular 'diff' to compare them. Glad to hear things are going to be changed in the (hopefully near) future. It's unclear if that particular change will be made, or if made whether or not it will stay. The requirement to supply add-time triggers has been identified (by a number of users), which requires a contact with the server. This has undergone some heated debate. -- Paul Sander | Lets stick to the new mistakes and get rid of the old [EMAIL PROTECTED] | ones -- William Brown ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs vs. clearcase?
These are not valid reasons. Here's why: - ClearCase MVFS is a filesystem that offers the same access to Unix tools as any other filesystem. They need not be ported to specialized environments to run under ClearCase. - ClearCase clients are available on several flavors of Unix, including Solaris, HP-UX, AIX, Linux, and others. Also, ClearCase views can be mounted via NFS so that unsupported systems can also use them. Consider being open-minded about ClearCase. Its capabilities are far superior to CVS, and it even supports concurrent development. On Nov 29, 2004, at 5:25 AM, [EMAIL PROTECTED] wrote: I have a director asking why I don't want to user the company's clear case server. One item I mentioned is the lack of integration into unix tools and the lack of a unix client. Are these good/valid reasons? What are other reasons? ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs vs. clearcase?
On Nov 29, 2004, at 8:53 AM, [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike [EMAIL PROTECTED] writes: I have a director asking why I don't want to user the company's clear case server. One item I mentioned is the lack of integration into unix tools and the lack of a unix client. Are these good/valid reasons? What are other reasons? Economic: - Cost per seat of support of Clearcase can be high For 50 seats, the price of initial licensing is about $4k/seat, then $400/yr thereafter. After the first year, its cost is in the noise floor. - Cost of View servers and Vob servers can be high But not significantly higher than the cost of the file servers you'd need to buy otherwise. Also, ClearCase offers enough opportunities for disk space sharing that you will likely need fewer of them. On the other hand, your network must be rock solid, and it must be fast; this may be an issue for some shops. If you're worried about this, consider using ClearCase snapshot views, which are more like CVS workspaces. - Technical training/expertise of the support staff favors CVS, so you need to train or hire Clearcase administrators. This is true. Political: - Many people do not trust the security of running a system that needs to modify the operational integrity of the kernel on both their clients and servers in order to operate effectively with Clearcase. The drivers supplied with ClearCase undergo a commercial grade quality assurance program, and their reliability is comparable to the kernel. The application itself also undergoes a commercial grade quality assurance program, a claim that CVS cannot make. - Clearcase is a primarily US-based SCM system while CVS is used by a large part of the international community. Depends on where you draw the bar that qualifies primarily. Last I heard, 30%-40% of ClearCase revenue comes from outside the USA. It's used heavily in India, Israel, and the Arab world. Technical: - If you already have a highly integrated environment using CVS, you should be able to write a technical paper on the cost of the transition from CVS to Clearcase for your particular area. I was able to convert a CVS-based shop to ClearCase, including some 400k lines of code in a week, and supplied daily conversions while the development groups switched over. - Technical training/expertise of the support staff favors CVS, so you need to train or hire Clearcase administrators. This is true. - Adding additional features to CVS is possible as you have the source, forcing IBM to change anything for you is not as easy. On the other hand, some believe that ClearCase does everything already. :-) It certainly supplies most of the features requested in this forum to be implemented in CVS. Also keep in mind that such claims as the above are only theoretical; source code doesn't make up for bad design, and I have personally have been unable to implement certain capabilities well with CVS because its architecture simply wasn't compatible with the problem I needed to solve. Ideological: - The future of Open Source development looks bright and you wish to attract Open Source community into joint development with one or more of your projects. Many companies don't care about this... Social: - Your developers will quit if they are forced to use Clearcase. In practice I doubt this is true. I know of two cases where the developers would have been ecstatic to use anything other than CVS. Ask around before making this claim. - Your developers will require many hours or re-education if they are forced to transition to a new SCM system and they do not like change. I had developers productive with ClearCase after a 1-hour lecture and 30 minutes' practice. The learning curve for the everyday stuff is pretty low. The learning curve for ClearCase in total is high, but most users don't need to access its complete functionality. Is your company able to get an agreement to escrow the source code for ClearCase should the vendor (IBM now owns Rational which purchased Pure which purchased Atria that originally wrote ClearCase) choose not to continue to provide the product at some future date? There's little need for this. Once you have purchased ClearCase licenses, they don't expire. So as long as you have compatible hardware and OS, you can access ClearCase. If maintenance stops for whatever reason (by the customer's choosing or not) then it's relatively easy to pluck out the data and metadata to convert to something else. If you have a large invested use of 'cvs' in your shop, then transition to clear case could be expensive. Certainly there are different administration problems with the extra hardware needed for View and Vob servers and the cost of doing distributed development using MultiSite can be high in terms of dollars and man-hours of effort.
Re: new user - do people store compiled code under cvs
People do, but in most cases it's not considered best practice. If you can reproduce the binaries from source, then don't put them under CVS; tag the sources and store the environment in a reproducible way. If the binaries are not reproducible from source, then there are two schools of thought. The first is to install the binaries in some well-known place and treat them like any other aspect of the build environment. The second is to apply the rigor to the binaries like any other file that can't be reproduced without manual intervention (i.e. source files) and check them in and write a build/deployment process to match. Heated debate supports both practices. On Nov 29, 2004, at 1:39 PM, [EMAIL PROTECTED] wrote: ? That is, would you save versions of things like executables, p-code, or DLLs? My gut says no, better to pull the source code for the version/revision we want to run/test/distrubute and compile from that whenever we need it. But what do people generally do? ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
On Nov 19, 2004, at 10:28 PM, [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sander wrote: This is why I hate the -n option of the checkout/commit/tag/update commands and advocate its removal from CVS. What in the world are you talking about??? -n prevents changes from being made anywhere! On the server or in the workspace! Why in the world would you care if the user can run a command which does nothing except tell the user what it would do if they actually ran it without - -n?!?!?!?!?!?!?!?!??!?!?!??!?!?!?!??!?! Kindly double-check the manual and the code. There's this: cvs -n commit ... and there's this: cvs commit -n ... There's a difference. The former means don't change disk. The latter means don't fire *info triggers. I believe that the latter should be removed, but that's just me. The latter *were* removed, over a year and a half ago, prior to the CVS 1.11.7 and 1.12.1 releases. References to the command option `-n' were removed from both the source and the manuals, for exactly the reasons you suggest they should have been. I did the work myself. There should be some emails discussing it in the archives, if you are interested. Cool!! :-) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
On Nov 19, 2004, at 6:38 AM, [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sander wrote: It's simpler, but neither safer nor saner to wrapper script around the client. The reason is this: If you enforce policy but give the user an avenue to circumvent it, the user will do so. If you're serious about enforcing policy, then you must have a way to build it into your tools in a way that user cannot defeat. In CVS (and indeed most if not all existing version control systems), that means spawning trigger scripts from within the tool, because wrapper scripts are trivial to defeat. This argument is not applicable to workspace changes. The user can manually edit the CVS/Entries files to add or remove a file locally without ever contacting the server. Your proposed hook would never run in this case. This is a trivial hack and, in fact, there are already scripts out there that will do just this without the user even needing to learn the trivia required to edit the files by hand. If you truly believe that, If you enforce policy but give the user an avenue to circumvent it, the user will do so, then your proposed hooks would offer absolutely no improvement over the status quo for your reported purposes. Like I said in an earlier post, I also don't believe that the user should be given the ability to corrupt his metadata. But I won't argue about it, and acknowledge that with CVS it's a possibility. Also recall that there was agreement that the add hooks should fire before the commit triggers at commit time, so whatever they do would be done regardless. It's just a matter of timing. And if the user bypasses the trigger and gets bitten later, so be it. Remember the very strongest bit of advice for using CVS is to update and to commit early and often This is true, but it remains a common belief that nothing should be committed until it's ready for unlimited use by the rest of the project. As long as that paradigm holds, work will continue to be done for long periods of time between commits. Your users should be committing changes to branches until they are ready for shared branches. There is no excuse for what you describe except ignorance or laziness. I agree. But I play with what I'm dealt. BTW, using the submit/assemble mechanism discussed here in the past, it is possible to commit to shared branches under certain conditions and still have an efficient (and very livable) process. But that's a different topic. Claiming that the hooks are not needed in the context of current use is meaningless because the hooks do not currently exist. Such arguments can only be made if one can demonstrate that existing hooks are not used in a meaningful way. On the other hand, we have stated requirements where existing users find existing capability to be inadequate. This is compelling reason to add the requested feature. Sure, if the user needs to request the feature using `-C'. The would be no other excuse for a needless server contact after Greg's proposed patch otherwise (which states in detail the direction I've thought development needed to go for awhile), except possibly if the add would continue if the server contact failed, but the more I think about it, the more I think even this is inappropriate without the user specifying the option. Looks like this part of our argument boils down to whether or not the trigger should fire by default. You say no, I say yes. However, we can have our cake and eat it too, if add-time hooks are implemented in the following way (which I summarize from prior posts): - Register add-time hooks in a new *info file. - Invoke the registered script at both of the following times: - User invokes cvs add - User invokes cvs commit, before commitinfo triggers fire. - Give the user the ability to defeat the add-time trigger in one of two ways: - Turn it on by default but use -n at add time to skip it, as I recommend. - Turn it off by default and add a new option to invoke it. As I mentioned before, the user should have complete control over their workspace. This includes being able to add and remove files in their workspace even when they do not have write privileges on the server, much less without letting the server abort the addition via an external script. Any other solution would mean that users could not generate complete diffs based on data they were not ready to commit. (This problem of complete diffs is actually the status quo since add still contacts the server. CVS will not calculate a diff for files is not tracking, at least locally, so to get new files into a diff, they need to be added locally. Unfortunately, this currently means contacting the server and having write privileges in the repository in question, which means that this cannot be done against an anonymous repository, or indeed any where the user has no write privs, without hacking the CVS/Entries file to add files by hand.) Okay, I'm
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
On Nov 19, 2004, at 6:49 AM, [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sander wrote: There is a certain logic to having triggers gate changes to the repository. There's also a certain logic to having a tool prevent conditions that will later cause it to fail. Uncommitable changes are such a condition, and it simply makes no sense to allow adds to succeed when we know that committing those adds will fail. It does when they user is disconnected from the network or wants to generate a patch to mail to someone for review without committing the changes, at the least. The user should be able to make any changes they wish in their workspace. The server should only gate changes to the repository, except possibly when the user requests otherwise. Fair enough. There's another point I'll make but won't argue over: There's a limit to the amount of control a user should have, even over his own workspace. The user shouldn't be able to corrupt his metadata to the extent that it causes failures, for example. Duh, not via CVS anyhow. They can do anything they want with other tools in their local workspace. I hope you are not proposing CVS run setuid root and prevent the user from altering their own files? Regardless, I am hardly proposing that CVS destroy a user's metadata. Actually, all I'm suggesting is that we should maybe consider ways of moving CVS metadata out of the user's workspace. But that's a different argument, and one that I'm not willing to pursue right now. Why is having CVS aware of source files an enabler for producing patches? CVS will not generate patch data for files it is not aware of. For a new file to be listed in the diff, it needs to be added first. I don't consider triggers to be conveniences. If they are to enforce policy then they can't be defeated by the user. Your suggestion would be easy to defeat, regardless, and no policies should be enforced on the user's workspace without their request. This assumes that policies as set by project management are voluntary. People who bypass them have a way of affecting the project in ways that management won't tolerate for long. This is why I hate the -n option of the checkout/commit/tag/update commands and advocate its removal from CVS. What in the world are you talking about??? -n prevents changes from being made anywhere! On the server or in the workspace! Why in the world would you care if the user can run a command which does nothing except tell the user what it would do if they actually ran it without - -n?!?!?!?!?!?!?!?!??!?!?!??!?!?!?!??!?! Kindly double-check the manual and the code. There's this: cvs -n commit ... and there's this: cvs commit -n ... There's a difference. The former means don't change disk. The latter means don't fire *info triggers. I believe that the latter should be removed, but that's just me. However, if applied to the add command, it is more agreeable than the -C option as described above for human engineering reasons. Again, no! -n prevents any permanent changes from being made to the disk, anywhere! (I mention permanent because some temp files are created and used in the /tmp dir, but these are conveniences and safely go away when the command is finished so are irrelevant for our purposes.) `cvs -n add' would mean, CVS, tell me what `cvs add' would do, but don't change anything, meaning don't add the file! What I've been trying to say is that the following is agreeable: cvs add -n ... If this form of -n remains compatible with the other trigger no-op options (like cvs commit -n ...), then it could be put in the user's .cvsrc file to defer add-time triggers until commit time. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
On Nov 18, 2004, at 7:38 AM, [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- I still disagree, because some people like working from their laptop and wireless network connections are hardly ubiquitous yet. Work that a developer can do from their laptop off of the network can also provide additional productivity. It also means work a developer can do while the server is down. Well, I'm of the opinion that one shouldn't bother trying to use a client/server application while one is disconnected. :-) Systems like Monotone are better for what you're trying to do, where you can keep a local repository that syncs with others at appropriate times. Perhaps a -C option to `cvs add' similar to `cvs edit', where -C can be placed in the user's .cvsrc for the add command and the add will not be allowed unless the server contact and verification is successful. If you're going to use triggers to enforce policy, then the user really shouldn't have the option to turn them off. Triggerable events should fire the triggers in a reliable way or else there's no point to them and they should in fact be removed on the basis that they only add cruft. Deferring them is okay, even as a client-side option, provided the user can't defeat them completely and the user is willing to accept the risk of lost work during the deferment period. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
--- Forwarded mail from [EMAIL PROTECTED] [ On Wednesday, November 17, 2004 at 09:19:18 (-0800), Paul Sander wrote: ] Subject: Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes) It depends on the nature and extent of the changes. I can easily imagine scenarios in which lost productivity would be measured in days, even assuming that all files are ASCII. Your imagination is far too ripe with bizzare paranoia. It's backed by many years of experience. There is no trigger for cvs rm and there MUST _NOT_ be. I wasn't going to mention this, but since you brought it up, removals should also be triggerable events and the same philophy, whatever it is, should be applied to both add-time and remove-time triggers. I have experienced situations where users have removed and committed stuff that had bad effects on the rest of the project. Coworkers have experienced user errors that cleaned out the entire source base of a project, requiring many days to correct. It's situations like this where triggers like this are valuable because they can limit destructive changes to users who know what they're doing. There is no trigger for cvs add and there MUST _NOT_ be. Again here we disagree. Just because you can live without it doesn't mean the rest of the world can. We've already discussed how to add such a capability in such a way that it involves zero overhead for those who don't want it: Register no triggers and defer their enforcement until commit time. But for shops that NEED them, they can register the trigger and turn off deferment. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with importing third-party sources and adding/committing changes
--- Forwarded mail from [EMAIL PROTECTED] [ On Wednesday, November 17, 2004 at 09:46:55 (-0800), Paul Sander wrote: ] Subject: Re: Problem with importing third-party sources and adding/committing changes Paul you keep spreading myths and mistruths. I wish you'd stop. This is simply not true, Greg, and you owe me a public apology. As I say above it's the other way around Paul. If you cannot refrain from spreading myths and mistruths, especially in relation to what I have said then please DO NOT EVER respond to my posts, at least not publicly. As a rule, I don't attack a person's character whenever I disagree with them. Not even you, Greg. Though in a few of my less proud moments I have resorted to that tactic, and for that I apologize. However, my technical arguments are sound and are based on many years of real-world experience. And I will continue to defend them vigorously. I disagree with your claim that the commitinfo hook is sufficient. Certain policies, like naming conventions, are best enforced at add time. You have no idea what you're talking about. You consistently ignore current practices and the context of an idea and you consistently ignore previous arguments even if they've been beaten into your head by a dozen people before. I don't know what you're practicing, but it clearly doesn't match best practices that I've observed in a number of shops. There's a reason why I continue to dispute certain arguments, which is that I have experienced first-hand the down-side consequences of them. If some people choose not to learn from my bad experiences, so be it; just don't pretend to know what you're talking about. In CVS the add command is supposed to be equivalent and orthogonal to the rm comand. The _entire_ basis for this proposal is to stop having to have contact with the repo server during cvs add in the first place!!! Yep. And that's fine, provided CVS doesn't significantly change its feature set. If you're happy with that arrangement, and you seem to be, then fine. But if there's serious interest in addressing conflicting requirements that have been stated in the past, then some debate is indicated so that consensus can be built. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
--- Forwarded mail from [EMAIL PROTECTED] [ On Thursday, November 18, 2004 at 10:38:44 (-0500), Derek Robert Price wrote: ] Subject: Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes) Perhaps a -C option to `cvs add' similar to `cvs edit', where -C can be placed in the user's .cvsrc for the add command and the add will not be allowed unless the server contact and verification is successful. Which of course is an extremely stupid way to implement something that is done for the sole and lone reason of policy enfocement. ;-) It would be saner and safer and much Much MUCH simpler to just write a wrapper script for the CVS client and require (through external security measures, such as peer pressure and/or threat of dismisal) that everyone always use the wrapper script. It's simpler, but neither safer nor saner to wrapper script around the client. The reason is this: If you enforce policy but give the user an avenue to circumvent it, the user will do so. If you're serious about enforcing policy, then you must have a way to build it into your tools in a way that user cannot defeat. In CVS (and indeed most if not all existing version control systems), that means spawning trigger scripts from within the tool, because wrapper scripts are trivial to defeat. Remember the very strongest bit of advice for using CVS is to update and to commit early and often This is true, but it remains a common belief that nothing should be committed until it's ready for unlimited use by the rest of the project. As long as that paradigm holds, work will continue to be done for long periods of time between commits. Note that this is not what I teach, it's what I see. I would never, ever discourage someone from checking in their work, working or not (though I may recommend doing so on a private branch). But despite my teachings to the user community of the folly of their ways, this we will commit no line until its time mindset persists. (but of course only commit after compiling _everything_ one last time and doing at least a few tests! :-) (which of course implies that day-to-day work using CVS should never be done directly on a baseline branch either, assuming the project needs a working baseline at all times :-) Any fears about early policy enforcement not being possible at cvs add time are ungrounded and illogical in the context of how CVS is used in general. Also the fear about lack of a cvs add hook is pure F.U.D. given that cvs rm also lacks a similar hook (and it lacks it for the same reaons). Claiming that the hooks are not needed in the context of current use is meaningless because the hooks do not currently exist. Such arguments can only be made if one can demonstrate that existing hooks are not used in a meaningful way. On the other hand, we have stated requirements where existing users find existing capability to be inadequate. This is compelling reason to add the requested feature. CVS add and rm commands are intended solely to change the state of the working directory. They MUST NOT require access to the repo or the repo server. They are no different than vi except that they change metadata describing the state of the working directory instead of changing the content of a file. I define the add and rm commands as the actions required to make CVS aware of new artifacts or to remove them from existing configurations. How it does that is to me an implementation detail, and I don't care whether or not the tool considers it necessary to contact the server. However, in the event that triggers are added to track these events, they must be added in such a way that user's can't defeat them by applying more primitive operators or munging their environment. To me, that means building triggers into the server and making the client contact the server at appropriate times to fire the triggers. If there's a better way to do it, I'm open to hearing it. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
--- Forwarded mail from [EMAIL PROTECTED] Greg A. Woods wrote: There is no trigger for cvs rm and there MUST _NOT_ be. There is no trigger for cvs add and there MUST _NOT_ be. I have to admit, there is a certain logic to drawing the line at triggers for repository changes, not workspace changes. The user should have total control over their workspace and the server shouldn't be able to veto anything except changes to the repository. There is a certain logic to having triggers gate changes to the repository. There's also a certain logic to having a tool prevent conditions that will later cause it to fail. Uncommitable changes are such a condition, and it simply makes no sense to allow adds to succeed when we know that committing those adds will fail. There's another point I'll make but won't argue over: There's a limit to the amount of control a user should have, even over his own workspace. The user shouldn't be able to corrupt his metadata to the extent that it causes failures, for example. This still requires that `cvs add' of directories not alter the repository until commit. It also reminds me that allowing `cvs add' and `cvs rm' in a workspace without even write privs to the server has been on my wish list for quite awhile (this enables complete patches to be generated from a public repository by anybody). I'm guessing the proposal Greg is advocating would provide for this. Why is having CVS aware of source files an enabler for producing patches? I also still would not object to the a `cvs add -C' convenience hook which requested that the client contact the server and validate the add. Any team that valued this option significantly should find it fairly easy to enforce a policy of placing `add -C' in users' .cvsrc files. I don't consider triggers to be conveniences. If they are to enforce policy then they can't be defeated by the user. This is why I hate the -n option of the checkout/commit/tag/update commands and advocate its removal from CVS. However, if applied to the add command, it is more agreeable than the -C option as described above for human engineering reasons. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
--- Forwarded mail from [EMAIL PROTECTED] Derek Robert Price [EMAIL PROTECTED] writes: Mark D. Baushke wrote: Hi Greg, Is it reasonable to suggest that a addinfo trigger could be run as a part of the 'cvs commit' command should the client not happen to connect to the server for a 'cvs add' operation? It should probably run regardless since it would be much simpler than securely tracking whether the add on the client side had contacted the server. Good point. Yes! The idea would be that having simpler triggers for various kinds of policy makes the administration of a repository easier. In a similar manner a trigger for 'cvs rm' could be implemented to impose policy. Sure, but again, not by default. Sure. I think that it should be enabled by default, and the user can put the -n option in his .cvsrc file for the affected commands, both for add and remove. The reasons for this: - It maintains compatibility with existing commands. - The user is caught just once when the trigger fires. Recovery is to interrupt the client, edit .cvsrc, and re-run. In the converse, the user must ask for policy enforcement, and may never get around to it in violation of the project's policy. Unfortunately, there appears to be no way to countermand a -n option, so the only way to turn it off is to edit the .cvsrc file. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
--- Forwarded mail from [EMAIL PROTECTED] Paul Sander wrote: Keep in mind that, although Greg does not acknowledge it, a number of people in this forum have stated a requirement for an add-time trigger that could be used for such things as enforcement of naming conventions and access control. Such a feature (referred to in the past as addinfo) would reinstate the need to contact the server during additions. I would personally be loathe to make any feature that doesn't require a connection require one if it could be helped. In fact, I've actually been thinking about disconnecting some of the other functionality, such as cvs diff against the base version of a file. Perhaps if the connection failed and then the work was simply done locally, it would be acceptable. It's fair to say that the client shouldn't gratuitously contact the server. On the other hand, I think it's safe to say that several of us in this forum disagree over what is gratuitous. I happen to think that triggers should run on the server, and therefore any triggerable event should contact the server. Why is an add hook considered to be an improvement over the hook that runs at commit time? It's true that add and commit hooks can enforce the same kinds of policies as post-conditions of the commit. However, add hooks can enforce things like naming conventions. I'm working in a shop right now that prefers to have additions to the source tree (particularly new directories) be made by the architects of the project rather than the rank and file, and such a policy is best enforced at add time. The reason why I say these are best done at add time is because if the add succeeds then the user is likely to do a lot more work under the assumption that the subsequent commit will succeed (or at least not fail due to conditions created by the add). If the commit fails due to an improper add, then the user must re-do (or un-do) a bunch of work. All those hours of lost productivity could have been avoided by an add-time hook. The counter-argument is that CVS is not a project management tool, and that if the conditions I describe above come to be then it must a problem in that area. But keep in mind that hooks exist to enforce policies set by project management. If you want to blame violations of policy on bad management, then you might as well remove all hooks. If you want mechanized policy enforcement using hooks, then do it right, in all the places where it's needed. And I contend that add time is one place where it's needed. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
--- Forwarded mail from [EMAIL PROTECTED] Paul Sander wrote: It's true that add and commit hooks can enforce the same kinds of policies as post-conditions of the commit. However, add hooks can enforce things like naming conventions. I'm working in a shop right now that prefers to have additions to the source tree (particularly new directories) be made by the architects of the project rather than the rank and file, and such a policy is best enforced at add time. The reason why I say these are best done at add time is because if the add succeeds then the user is likely to do a lot more work under the assumption that the subsequent commit will succeed (or at least not fail due to conditions created by the add). If the commit fails due to an improper add, then the user must re-do (or un-do) a bunch of work. All those hours of lost productivity could have been avoided by an add-time hook. This might be true, but it seems to me that most damage due to your lost productivity could be fixed with a rename or two and maybe a few `sed' runs, in a few minutes. At least in an environment where most of the files concerned were text files, as will usually be the case using CVS. It depends on the nature and extent of the changes. I can easily imagine scenarios in which lost productivity would be measured in days, even assuming that all files are ASCII. It might be interesting to see Greg's patch, but yours wouldn't be a big deal either, I think, as long as the add went forward without the hook execution when the server could not be contacted. The thing is, if there's a triggerable event, the trigger must be able to halt the event. Unplugging the network interface to enable adding a directory is simply not acceptable. On the other hand, requiring all add hooks to be replicated at commit time would eventually catch the error, and it could be argued that someone who attempts such tricks gets what they deserve, but it's just easier and better all around to just make the trigger act like a trigger. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with importing third-party sources and adding/committing changes
--- Forwarded mail from [EMAIL PROTECTED] [ On Tuesday, November 16, 2004 at 23:53:40 (-0800), Paul Sander wrote: ] Subject: Re: Problem with importing third-party sources and adding/committing changes Keep in mind that, although Greg does not acknowledge it, a number of people in this forum have stated a requirement for an add-time trigger that could be used for such things as enforcement of naming conventions and access control. Such a feature (referred to in the past as addinfo) would reinstate the need to contact the server during additions. Paul you keep spreading myths and mistruths. I wish you'd stop. This is simply not true, Greg, and you owe me a public apology. If you had more carefully considered the proposal I've outlined in its entirety and in its proper context you would have sees that there clearly is not any need at all, ever, for any contact with the server in order to enforce any arbitrary policy implementing checks for added new files, etc. I understand your proposal clearly, which simply stated is a deferment of all repository action related to additions until a subsequent commit. This eliminates the need for the client to contact the server, assuming that no other existing features change. However, if additions are to be considered as triggerable events, and I argue that they should be, then the server must be contacted regardless of whether or not repository changes are deferred to commit time, so that the trigger can fire on the server. _NO_ change to the repository is made until cvs commit time and the existing commitinfo hooks are _MORE_ than sufficient by far to implement any of the hacks you suggest some folks might need. It's fine that no change is made to the repository until commit time. I have no argument with that, and to that extent I encourage that your patch be integrated into the definitive source. I disagree with your claim that the commitinfo hook is sufficient. Certain policies, like naming conventions, are best enforced at add time. It's true that commitinfo could eventually catch naming errors, but deferring that particular check leads to lost productivity while corrections are made after the failed commit. For an addinfo hook to work, the client must contact the server to fire the trigger and read its completion status. However, the addition of an addinfo hook violates one of your preconditions, which is that the existing behavior of CVS (outside of your patch) remains unchanged. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with importing third-party sources and adding/committing changes
Keep in mind that, although Greg does not acknowledge it, a number of people in this forum have stated a requirement for an add-time trigger that could be used for such things as enforcement of naming conventions and access control. Such a feature (referred to in the past as addinfo) would reinstate the need to contact the server during additions. On Nov 16, 2004, at 11:34 AM, [EMAIL PROTECTED] wrote: [ On Monday, November 15, 2004 at 14:43:06 (-0800), Mark D. Baushke wrote: ] Alternately, or additionally, my old cvs add proposal needs to be implemented. Could you restate it please? Is it just that you want a recursive 'cvs add' or is it something else? Much more: (note this is just a cutpaste from the copy I kept since it was last posted here -- I've not reviewed it in well over a year now, though it may have had some minor edits and corrections since last being posted) A Proposal to Avoid Immediately Creating Directories in the Repository == This proposal fixes the cvs add function so that it no longer handles directories in any special way and instead simply treats them as underlying structure that holds all the files apart. Together with this change will be bundled the total disconnection of cvs add from any repository actions (thus allowing cvs add to work properly on a disconnected client machine in all circumstances). In its entirety this proposal brings the cvs add user interface (command-line interface and resulting behaviour) into conformance with all other CVS sub-commands that operate from within a CVS working directory. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Merging contents of two repositories into a single one.
Don't forget to merge your modules and *info databases. These must be done by hand. On Nov 11, 2004, at 3:57 AM, [EMAIL PROTECTED]@dewire.kom wrote: Ivan Teliatnikov wrote: Hi there, Historically I have two CVS repositories located on the same CVS server. /opt/cvs/cvs1 /opt/cvs/cvs2 Each location has a number of independent projects. Is is possible to merge the two CVS locations into one without loosing history information? Yes. Every file is standalone. Just copy the content of cvs2 into cvs1. and merge CVSROOT manually.For those that has a ,v file you check out and make the changes. The other file can be merged using using a text editor. history can be merged using cat and sort. cat /opt/cvs/cvs1/CVSROOT/history /opt/cvs/cvs2/CVSROOT/history|sort tmp mv tmp /opt/cvs/cvs1/CVSROOT/history -- robin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Recoving branch point tag?
On a file-by-file basis, you can discover the sprout point version number for any branch. You do this by looking up the RCS magic branch number, which has the form sprout.0.n where there is always an odd number of periods. where sprout is the sprout point version number, and n is the branch number (containing no periods) spawning from that point. In the event that branches were created outside of CVS (i.e. RCS commands were used directly) then penultimate 0 (and the period following it) is missing. This also occurs with vendor branches, but for those the sprout point is always version 1.1. Once you have an exhaustive list of files and sprout points, you can try to discover the tag that was applied to the files by seeing which tags apply to all of the files at the discovered places. Alternatively, you can use the list to apply a tag after the fact to identify the sprout point. --- Forwarded mail from [EMAIL PROTECTED] Imagine I've got module foo which I've branched at tag X, and I branch off that in turn by doing something like: cvs get -r X foo cd foo cvs tag -b Y cvs update -r Y I do some work in the sandbox, commit the files, then blow away the sandbox. Is it now possible, from looking at the logs, to recover the information that X is the base of the Y branch? For a given file, it's easy to see the branching structure with respect to revision numbers. But, each file in the module will have its own set of revision numbers, and there can be many tags which correspond to a given revision. My suspicion is that the information I seek is not recoverable from the data stored in the repository. Am I right? I guess this is one of the things subversion will address? --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Projects with shared libraries
You can embed (or include) module C inside modules A and B in the modules file so that when users populate their workspaces with modules A or B they also get C. There are a couple of ways to do this so that C is a subdirectory inside A and B, or it can be on its own outside of the A and B directories. Based on your latest description, I think this is what you want, assuming that C is self-contained in its own directory structure. If the files in C are interspersed with those of A and B in the same directories, then you're stuck; CVS can't combine files that way very well. It's theoretically possible to exhaustively list all of the appropriate files in the modules file, but it's a very inflexible mechanism when used in that way and unwanted things tend to appear during updates. If you're looking to have some kind of reference (e.g. symbolic link) created automatically in the user's workspace when fetching A or B, you're stuck. That's best done by the build procedure, and you need to have a copy of the correct version of C in a well-known place before the build starts. On Oct 22, 2004, at 6:48 AM, [EMAIL PROTECTED] wrote: Paul, Thanks, your answer is clear but the problem is another. Let me explain, for example, I have 3 projects A, B and C. C is a set of generic libraries, same frameworks that A and B need. I'm using RedHat Linux as repository server with WinCVS clients. The clients import a CVS module A, or B and need C to work. I want A and B to reference C inside their modules. I'm not worried about build links. Is it possible to have virtuals folders and files inside A and B that reference C (in other words, symbolic links to physical files or folders to module C), and when developers IMPORT A or B, download the set of libraries referenced by these virtuals folders / files, and then they don't have to download module C, this is transparent for them. Best Regards, Paola Paul Sander wrote: I think it me who didn't communicate clearly! :-) The problem you describe appears to be a classic software reuse issue, in which you want to reduce the overhead to maintain some subset of your code that finds its way into many products. There are many ways to share code, each with their advantages and drawbacks. Methods include cutting and pasting lines of code in the source files, copying entire source files, building libraries and linking with them, build macros and templates, invoking executables, and many more that involve sharing artifacts not known by the build procedure per se (i.e. reusing various parts of the design and the code that follows from them). If I understand your specific issue correctly, you have some source code that you build into a library that links into several products. The library may be built and maintained on its own schedule, and the products upgrade their version of the library at their own convenience. The library builds are probably kept in well-known places with the expectation that product builds will use them. However, the reference and reproducibility requirements of the overall process have added complexity because the product builds must somehow track which versions of the library they use. The library's build procedure must be such that any version of the library must be reproducible, where the version is supplied as an argument from a product build. If you're building on Unix, then picking up the libraries at link time is a matter of setting the proper search paths and naming the desired libraries. This is usually done with options like -L and -R to set search paths, and -l to identify the libraries. It's easy to identify the names of the libraries to supply with -l options. The challenge is to set up the search paths. The reason for this is because the search paths themselves must be (or derive from) arguments passed to the product build, and the arguments must be stored and tracked for repeatability and reproducibility. There are a number of methods to store such arguments. One is to list the references in environment variables, and version control the script that sets them. Another is to compute them during a setup step and check them in. Yet another is the buildref method, which is a kind of publish-and- subscribe method where reference builds publish their interfaces and product builds refer to those interfaces (and remember which reference builds they used). Since you're at Oracle, you probably also have ClearCase at your disposal. Its wink-in (build avoidance) capability built into Clearmake offers yet another useful opportunity for reuse. --- Forwarded mail from [EMAIL PROTECTED] I appreciate your answer, but I think I didn't explain my problem well. The projects I mentioned are independent from each other, and they share common libraries. I would like to have only one copy of these shared libraries, and a reference to them in each of my project modules. This way, I wouldn't have duplicated
RE: Build environments using CVS
--- Forwarded mail from [EMAIL PROTECTED] Brian Blignaut wrote: Firstly let me say that if this is not the appropriate place to ask this question I apologize, I am just not sure where else to post. Yes, this is the appropriate place to ask. I am trying to setup a build process that works with CVS tags and am having a bit of a problem. The Build Environment 1. Development - developer's adding/changing/fixing code 2. Testing - with software testers, and test data - TEST tag 3. Release - Software built for release to client - LIVE tag The Problem Deleting files from CVS retains the TEST, LIVE tags. As a result the files that not meant to be built are being included in TEST, LIVE builds. It sounds to me like you are re-using the tags TEST and LIVE. I'd recommend using unique tags instead, e.g. proj-rev-x-y-build-z If you really want to re-use TEST and LIVE tags, then you should use these in conjunction with the unique tags. You will have to manually delete the TEST and LIVE tags before you remove the file. You might want to write a small script to do this, and encourage everyone to use the script rather than directly issuing the command 'cvs remove'. Actually, you can probably enforce this using the commitinfo script - if a file is being removed, and it has a TEST or LIVE tag, the commitinfo script can abort the commit with an error message telling the user to remove the tags first. You might also consider using a change control method that's not based on tags. Search the info-cvs archives for submit/assemble for discussions on a handoff and integration method that can handle the addition and removal of files, and also collects changes in a way such that they can be reversed. This method has been used with great success on a number of projects of varying size. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Projects with shared libraries
You could add the library to your product modules and build them all at once. However, I find that a better method is to subject the libraries to the same kind of control as the rest of the product (with regular builds, tagging sources, defect tracking and change control, etc.) and provide a set of well-known interfaces that can be used and tracked by the product builds. The references themselves should be versioned in some way, via source-controlled build scripts or environment settings, or by sampling the build environment and checking it in. A method that I've used with great success on many projects is the buildref method. You can find an implementation at the following URL: http://www.wakawaka.com/source.html --- Forwarded mail from [EMAIL PROTECTED] I have some projects that share some libraries. Does CVS allow to have a common set of libraries that will be used by different projects?, in other words, I need one copy of these libraries and a reference to them in each of the other projects. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Stale NFS handle
I would expect to see errors like this if your CVS server has mounted the repository over NFS, and the NFS server rebooted. If this is indeed the case, then you must unmount the NFS partition on your CVS server, then re-mount it. (Rebooting the CVS server might be easier.) You might also consider storing your repository locally on your CVS server. --- Forwarded mail from [EMAIL PROTECTED] Using cvs1.11.17 over ssh, I started getting this error after the server was rebooted. What can I do to alleviate this? cvs [commit aborted]: error closing lock file /project_dir/,tester.cpp,: Stale NFS file handle cvs commit: error closing lock file /project_dir/,tester.cpp,: Bad file descriptor --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Projects with shared libraries
I think it me who didn't communicate clearly! :-) The problem you describe appears to be a classic software reuse issue, in which you want to reduce the overhead to maintain some subset of your code that finds its way into many products. There are many ways to share code, each with their advantages and drawbacks. Methods include cutting and pasting lines of code in the source files, copying entire source files, building libraries and linking with them, build macros and templates, invoking executables, and many more that involve sharing artifacts not known by the build procedure per se (i.e. reusing various parts of the design and the code that follows from them). If I understand your specific issue correctly, you have some source code that you build into a library that links into several products. The library may be built and maintained on its own schedule, and the products upgrade their version of the library at their own convenience. The library builds are probably kept in well-known places with the expectation that product builds will use them. However, the reference and reproducibility requirements of the overall process have added complexity because the product builds must somehow track which versions of the library they use. The library's build procedure must be such that any version of the library must be reproducible, where the version is supplied as an argument from a product build. If you're building on Unix, then picking up the libraries at link time is a matter of setting the proper search paths and naming the desired libraries. This is usually done with options like -L and -R to set search paths, and -l to identify the libraries. It's easy to identify the names of the libraries to supply with -l options. The challenge is to set up the search paths. The reason for this is because the search paths themselves must be (or derive from) arguments passed to the product build, and the arguments must be stored and tracked for repeatability and reproducibility. There are a number of methods to store such arguments. One is to list the references in environment variables, and version control the script that sets them. Another is to compute them during a setup step and check them in. Yet another is the buildref method, which is a kind of publish-and- subscribe method where reference builds publish their interfaces and product builds refer to those interfaces (and remember which reference builds they used). Since you're at Oracle, you probably also have ClearCase at your disposal. Its wink-in (build avoidance) capability built into Clearmake offers yet another useful opportunity for reuse. --- Forwarded mail from [EMAIL PROTECTED] I appreciate your answer, but I think I didn't explain my problem well. The projects I mentioned are independent from each other, and they share common libraries. I would like to have only one copy of these shared libraries, and a reference to them in each of my project modules. This way, I wouldn't have duplicated libraries' code in the projects that are sharing them. And when I upgrade the libraries (i.e. when a new release appears) I would have to do it only once. I'm not sure if CVS has this feature, I'm only asking if any of you has done this before or knows how to do it. Paul Sander wrote: You could add the library to your product modules and build them all at once. However, I find that a better method is to subject the libraries to the same kind of control as the rest of the product (with regular builds, tagging sources, defect tracking and change control, etc.) and provide a set of well-known interfaces that can be used and tracked by the product builds. The references themselves should be versioned in some way, via source-controlled build scripts or environment settings, or by sampling the build environment and checking it in. A method that I've used with great success on many projects is the buildref method. You can find an implementation at the following URL: http://www.wakawaka.com/source.html --- Forwarded mail from [EMAIL PROTECTED] I have some projects that share some libraries. Does CVS allow to have a common set of libraries that will be used by different projects?, in other words, I need one copy of these libraries and a reference to them in each of the other projects. --- End of forwarded message from [EMAIL PROTECTED] --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Preventing Dirty Checkins
--- Forwarded mail from [EMAIL PROTECTED] Maarten de Boer wrote: One catch I can see with this approach is the platform. For example, our development platform is Windows using Microsoft Visual Studio, and our repository is on a Solaris machine. So, the testing machine could be Windows with Visual, which could compile, test, and move the compiles-correctly tag. But that's a different approach from what was suggested. The suggested approach was a commitinfo script. Commitinfo runs *only* on the server. I'm not saying the suggested approach was the best, or even workable. I'm just pointing out a potential problem with the suggestion. Another is what to do if your shop compiles on more than one platform. How do you test that the compile is successful everywhere? About the third time you do this, you start thinking that scheduled builds combined with good change control and a promotion system look pretty good. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: waiting for lock message on cvs
The other thing you should do is avoid using kill -9 as your first resort to get rid of something you don't want. It's a kill with extreme prejudice command that blasts the process slot without giving the application a chance to clean up after itself. Try using ctrl-C, then just plain kill, then maybe kill -1 before going for the throat. Had you done this instead, CVS' signal handlers would have cleared the locks for you. Melroy [EMAIL PROTECTED] writes: I did a very stupid mistake while trying to commit something ona new machine. Since I am not familiar with vim, I killed th cvs commit job (using kill -9 pid). Then when I set the editor to be emacs it and tried to commit the same file I get the error message cvs commit: cvs commit: [11:28:28] waiting for melroy's lock [11:28:28] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing Dirty Checkins
--- Forwarded mail from [EMAIL PROTECTED] Ones Self wrote: Hi, I'm running a CVS server which compiles and tests the current files in CVS every hour. I would like to make new checkins available _only_ if they compile and pass the tests. So, if a user checks in something which does not compile, for example, other users who check out at that time will not get the new version until the problem is fixed. Everytime you do an update, you know you're getting a clean version of the source; one that compiles, and in which the tests pass. make your command (or script) build the software and if it fails return nonuser. Checkin's will take a long time if you force 'make clean world', but you can choose the implementation level that is right for you. This way only acceptable things make it in the base line. opinionThe better method would be to hire engineers who understand the process of making good checkins, and/or use a process that involves the engineer doing the check before committing and dock his/her pay for bad commits\opinion, but you may implement what ever mechanisms make you or your boss happy. Yet another method is to divorce the notion of latest checked in from eligible for build. I personally would never discourage anyone from checking in their work, and I found that providing a handoff method in which the user explicitly guarantees that the code will build is a useful tool. Collecting up the bits for inclusion (or exclusion) in the next build is a simple form of change control that also improves the quality of the builds overall because changes can be undone (sometimes automatically!) under error conditions. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Preventing Dirty Checkins
--- Forwarded mail from [EMAIL PROTECTED] Ones Self [EMAIL PROTECTED] wrote: I'm running a CVS server which compiles and tests the current files in CVS every hour. I would like to make new checkins available _only_ if they compile and pass the tests. So, if a user checks in something which does not compile, for example, other users who check out at that time will not get the new version until the problem is fixed. Everytime you do an update, you know you're getting a clean version of the source; one that compiles, and in which the tests pass. I don't think you can do that. Well, you could trigger a full recompile from commitinfo and allow the commit only if the build succeeds, but your commits would be a bit sluggish that way. What you *could* do is trigger the build from loginfo (post-commit) and update a moving tag if the build is successful. That way your trunk can contain garbage, but the last successfully built commit will have an unambiguous marker on it. Your users can choose the unstable tip, cvs checkout foo or the last known good version, cvs checkout -rLAST_GOOD foo but in the latter case they won't be able to commit changes. (Well, they could start a branch, but that's taking us off-topic.) The loginfo trigger would be asynchronous, as in https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC175 and there would be negligible delay to a commit. Simple question: why can't the developers do a top-level make test before committing, and sidestep the question ? Or do the unit tests take that long to run ? If the latter, you'll have to guard your build-test-retag script against multiple instances of itself. Seems like the triggers and build procedures could conspire to enforce a policy that developers complete successful builds, too. The build procedure could have a target that lists its products, one of which be a summary report. The trigger could audit the summary and make sure that the targets are all newer than the sources and fail if anything was done out of order. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Modify files on before commit using loginfo?
Have you considered something like this? Create a special target in your makefile that performs all the auditing of your process that you want. Its prerequisites should be all of the header files you're concerned about. Put it under CVS control and commit it with all of your sources, and apply the necessary verification using the *info hooks. List it in the prerequisite list of all of your first-order derived objects (e.g. your .o files, but it need not actually be used in the recipe). Creating the audit file would be a simple matter of reading the user's environment and running a few simple programs (e.g. cpp and grepping its output for known strings). The verification would be to compare the user's audit file against a trusted template. You could also add more verification into the recipe that builds the audit file, and fail the build if it doesn't match the trusted template. This isn't a foolproof method to prevent the type of error that you describe. Touching the audit file avoids rebuilding it if its prerequisites change. It also causes unneeded compilations by introducing extraneous prerequisites, but this can be improved by writing an audit file for every shippable. --- Forwarded mail from [EMAIL PROTECTED] I'd like to provide an example of a case where something like this would be useful. I want to prevent people from building a program that was compiled with 2 different versions of a C++ header file. We already use the cvs ident command to look for problems like this, but it would be even better to prevent it in the first place. It would be great if we could declare a global variable with a name that contains the header file name and version number, e.g. for version 1.17 of foo.h, Extern int foo_h_1_17 = 0; Then in foo.c, we can define this global variable. If someone has compiled some file with version 1.16 of foo.h instead of version 1.17, they will get a linker error. CVS has $Id$ and $Revision$ keywords, but they can't be used to build this variable name. For one thing, the name can't have dots in it. Running a script to modify the file either on checkout or commit would allow us to declare the variable. If anyone can suggest a scheme to automate a process like this, it would be greatly appreciated. -- Forwarded mail from [EMAIL PROTECTED] Agreed. Make the user make the change you want committed. Supply a script to do it if necessary. Then use the *info capability to verify that it was done. --- Forwarded mail from [EMAIL PROTECTED] Anders Carlberg [EMAIL PROTECTED] writes: Is it possible to modify the files before they are commited to the repository using loginfo or commitinfo? At loginfo time it is already too late, the file has been committed to the repository. At commitinfo time, you have access to the server side copy of the files (or the original files if in :local: mode), so it may be possible to whack in changes. Doing so is a very bad idea as it introduces entropy that is not controlled by the user into the process of trying to accurately record the state of files that 'worked' for the user. How should I do this? You should not do it. If you choose to do it, you may find yourself in a world of hurt eventually. Is there a file stream I can read and write to? Not really. Or should I do this via CVS commands (checking out and commit) (but then the files get a new version? Or?) ? CVS is bright enough not to provide for this kind of lunacy/idiocy. Is there anyone that has done something like this? Probably, folks have been abusing CVS in ways it was never intended to be used for many years now. This does not make it a good idea. --- End of forwarded message from [EMAIL PROTECTED] --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Why's it a sandbox?
--- Forwarded mail from [EMAIL PROTECTED] That's why some people call them playpens instead. :-) Oh, so now we're toddlers who can't even be trusted with sharp instruments. Hmmm ;-) Surrounded by nets, noisemakers, and things to pound on... --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Why's it a sandbox?
--- Forwarded mail from [EMAIL PROTECTED] On Wed, Aug 18, 2004 at 05:28:28PM -0400, Jim.Hyslop wrote: OT rant Why do people call these sandboxes? I'm a professional software developer, not a kid playing in the sand. /OT rant Hehehe...I think sandbox is a cool term and never thought of it as at all demeaning. Sandpit, on the other hand, quickly made me think maybe someone was trying to be politically correct or something. Personally, I much prefer sandbox over an overzealous attempt to be PC any day. :-) And then there are sandboxes of the house cat variety... That's why some people call them playpens instead. :-) --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Setting the rules and politics for CVS...
Take a look at the CMBoK (CM Book of Knowledge) at http://www.cmcrossroads.com/ and then look for Brad Appleton's wiki of CM patterns, referenced at that site. --- Forwarded mail from [EMAIL PROTECTED] I'm not too sure the last section was a question or a statement, but if anyone knows of a well maintained site, or news group listing the less technical experiences ( and perhaps technical solutions ) that people = have had, perhaps in the form of case studies then I for one would be = interested in it. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: binary files bad idea? why?
--- Forwarded mail from Greg Woods: [ On Tuesday, July 6, 2004 at 15:18:50 (-0700), Paul Sander wrote: ] Subject: RE: binary files bad idea? why? And BTW, you keep waving over RCS compatability with arguments about minimum reproducibility that simply do not wash. RCS compatabiltiy means _all_ of RCS' features, warts, and concepts. More about the reasons for this below. As long as the rcsfile(5) specification is met, then all of RCS' features, warts, and concepts will follow. That specification also allows specifically for extensions to be introduced in particular ways, and RCS is written to accomodate such extensions by ignoring them while allowing other tools that scan RCS to store their own semantics. There is absolutely no reason why such tools should not be written, and any tool that cannot work in such an environment is inherently broken because it violates the rcsfile specification. In the mean time, and in the real world, RCS (and thus CVS) and all the tools they use and are used with them work _best_ and primarily with text files. I.e. until someone provides working code that makes the diff/diff3 toolset used _internally_ in CVS (_and_ RCS) to be selectable (on a per-revision basis), there's no point to even pretending that non-text files can be handled generically by CVS. This is nuts. Differencing algorithms that rely on longest common substrings will remain the best algorithms for storing deltas for a long time to come, regardless of the type of data being stored. Applying a different algorithm for every revision just won't go. And BTW, the point about on a per-revision basis is/was supposed to be a strong clue to you to show just how hair-brained and nearly impossible to achieve your ideas are. It's also a _necessary_ requirement for both RCS and CVS, which manage _files_ and groups of _files_, but not the structure of the grouping. You keep making the mistake of claiming that the differencing algorithm that computes the deltas, and the differencing and merge tools that manipulate and present the content of the revisions are inextricably linked. They are not. However, I agree that in that context, the differencing and merge tools must be compatible with the content of every revision stored in an RCS file. The easiest way to do that is to make sure that every revision has the same kind of data. The problem is that CVS doesn't make such a guarantee at this time. For a very long time I have argued that CVS should record in the admin section of every RCS file the type of data stored in it, and that CVS should poll that data type to select the proper tools to apply to provide the diff and merge capabilities. This is one way to guarantee that all of the revisions, and therefore all of the combinations of data fed to the tools, are indeed compatible. The there's a price, and that is that no position in the filesystem can ever be reused for a different type of data than has ever been stored there before. That means e.g. that README files can't change formats between plain text, rich text, MS Word, or whatever formats. This is clearly an unacceptable condition as long as software developers wish to evolve their designs. It is possible to meet both requirements: Guarantee every revision in an RCS file to contain the same data type, and allow the users to make arbitrary changes to their source trees. And the way to do that is to change the way that CVS maps files in the user's sandbox to the RCS files in the repository, so that at any given time the working file maps to the correct RCS file but the correct RCS file may be different at different points in the project's lifetime. That same change also enables other things, like the ability to genuinely rename a file. Therefore, to accomodate multiple data types, it is in fact a _necessary_ requirement for CVS to track the file structure in addition to the content of each file. The main idea of change management is to capture and identify _changes_, not to record exact replicas of specific revisions across time. The latter comes from the former, not the other way around. Changes are best specified as the the edit actions that were done to make them. Why do you think it is that deltas are stored as edit scripts in both RCS and SCCS files? I'll tell you for certain it wasn't just because there were already well known algorithms (and ready implemented tools) to create and make use of those edit scripts (though that was of course a big part of it). First of all, the motivation for storing deltas was for storage efficiency. This goes all the way back at least to Brooks (The Mythical Man Month). Second, SCCS doesn't store edit strings; it stores interleaved deltas which are more akin to #ifdef constructions. The deltas stored in RCS are not the same as the edit actions that the user took. In the case of RCS, they're approximations, but when examined in a context that understands the semantics of the content, e.g. a C
Re: binary files bad idea? why?
--- Forwarded mail from [EMAIL PROTECTED] [ On Thursday, July 8, 2004 at 23:01:09 (-0700), Mark D. Baushke wrote: ] Subject: Re: binary files bad idea? why? IF we assume that the 'cvs update' of a particular file in a user's sandbox needs to do a three-way merge (checked-out version, latest-version and locally modified version) AND we assume that there is a hint for the CVS server to use some program that looks just like diff3 as to arguments, but (possibly) interprets (say a canonical HTML structure ignoring whitespace) the file differently than the default diff3, AND the diff3-like-progam for the checked-out version and the latest-version specifies the same diff3-like program, THEN Paul's request for an extension seems reasonable to allow this kind of an extension. Except those assumptions in total are bogus (and unrealistic), and they do not leave one with a true RCS-compatible repository either. Mark's first assumption is totally reasonable, and it matches perfectly the common usage model of CVS. The second assumption can be implemented by storing the hint in a newphrase in the RCS file. I challenge you to find a situation in which adding a hint in this way breaks RCS compatibility. Chances are that the breakage willbe in some third party tool that doesn't understand newphrases. In that event, it's the third party tool that break RCS compatibility, and you can't lay the blame on CVS. Remember the whole point of RCS compatability is to be compatible with other tools that understand and use the RCS ,v format. It's not just a convenient delta compression mechanism. However the particular form of delta compression used universally in the RCS ,v format is integral to everything I know of which would rely on RCS compatability. Okay, how does adding a newphrase break other tools that rigidly adhere to the rcsfile specification? Also within the architecture of CVS it's totally bogus, stupid, and very short-sighted, to go blindly off and invent yet another ugly brain- damaged hack that doesn't fully account for the fact that some signifiant number of files' internal structure type (for lack of a more succinct term) _will_ change over time in any sizable project. The reason that the internal structure of a file changes over time is because CVS makes no guarantee that every version of a file has the same type over its lifetime. There are ways to make such guarantees, but at present they're limited to adoption of crippling policies or changing the CVS implementation. BTW, it turns out that the specific change that makes this guarantee also fixes other problems in CVS. CVSwrappers is bad enough for this reason alone already (never mind the other brain-damage it implies) and luckily it's not used by many otherwise sane people. Any extension mechanism _MUST_ be per-delta, but of course that goes against the very nature of RCS (and there are already a vast number of attributes which are not per-revision but should be to get to this level of flexibility). It could be per-delta, but in my opinion that is a poor implementation. The guarantee of one data type per RCS files makes a whole lot of problems of this nature just disappear because all possible combinations of data applied to the extensions match. I believe that this is very much in line with the RCS way. Just take a look at keyword expansion if you want a built-in feature that suffers the same problem. It also only works if the data type is similar for every revision. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: How to tell CVS that it should use the proper date/time
--- Forwarded mail from [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: If you mean you want checkout to record the current timestamp of the file rather than the time of the checkin, that would also break things like make. I'm not sure I follow this. How would using the timestamp of the file instead of the time of checkin break make? Presumably, the file's timestamp would be older than the time of the checkin, and on a fresh checkout there won't be any targets (e.g. *.o) at all. Hmmm... well, I guess I'm assuming that the targets will be created in the same directory as, or a subdirectory of, the source directory. Is that a poor assumption? Might the targets be in a directory completely outside of CVS's knowledge? The problem is that the CVS doesn't guarantee that the files are copied into the workspace in the same order in which they were checked in. So for derived files like y.tab.c and y.tab.h that might be checked in (these might be bad examples, but you know what I mean), unpleasant things can happen if their timestamps come out in the wrong order. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: binary files bad idea? why?
--- Forwarded mail from [EMAIL PROTECTED] [ On Friday, July 2, 2004 at 12:34:42 (-0700), Paul Sander wrote: ] Subject: RE: binary files bad idea? why? --- Forwarded mail from Greg Woods: It is literally _impossible_ to manually resolve (with any degree of correctness) any three way merge with conflicts in any ``binary'' file, regardless of whether it has been encoded as text or not. It IS possible, using a tools that understand the content of the file. I thought we had agreed a half dozen years ago ore more that the definition of binary file as the phrase is usually used in this forum means binary opaque file. I thought you'd at least account for this interpretation if I used double quotes, but clearly you'd rather debate meaningless nonsense regardless. I recall no such agreement. I do agree a fair amount of discussion that makes the distinction between mergeable content and non-mergeable content, where it was agreed that there was a high degree of correlation between binary files and non-mergeable content, but there was also wide acknowledgement that text-based content can be non-mergeable (e.g. uuencoded binaries), and that binary content can be mergeable (e.g. mark-up formats like MS Word). If you can come up with a time frame and subject thread in which such agreement was made, then I'll be happy to review the entire discussion and debate its merits. I.e. it is not possible, by definition, to resolve merge conflicts in any ``binary'' file. Period. If the ``binary'' file is truly opaque, which is to say that you have no knowledge of its structure and can't find a tool that does, then I agree that a merge conflicts are impossible to resolve. However, not all binary files have opaque structure, and I maintain that it is indeed possible to resolve merge conflicts if you know something about their content. While researching your claim of an agreement, I discovered the following: From: Greg A. Woods Subject: RE: cvs update; merge Date: Wed, 29 Aug 2001 16:55:01 -0400 (EDT) [...] Non-mergable files can NEVER be easily and generically handled by CVS as it stands today. Until someone provides working code that makes the diff/diff3 toolset used internally in CVS (and RCS) to be replacable (preferably on a per-revision basis), there's no point to even pretending that presently non-mergable files can be handled generically by CVS. (Of course with a selectable diff/diff3 algorithm you can treat truly binary-opaque files with a copy-to-merge mechanism, though even that's hardly 100% satisfactory.) As for binary from the fopen(3) perspective of stilly petty OS differences in EOL and EOF conventions, well since CVS cannot really properly support non-mergable binary files the only correct thing to do is to always treat all files as text files and to always apply the local libc fopen(foo, *t) conversions for the given client platform (i.e. to always normalize the text stored in the repository into the Unix/ANSI/ISO-C standard format where binary == text and EOL is '\n' and there is no EOF character). [...] Your first sentence in this quote says it all. The code you suggested in the second sentence was posted to this forum just three weeks later. Taking that paragraph in its entirety, it seems almost as if we're in violent agreement. As for the second paragraph, the requirement here is that RCS and CVS faithfully reproduce the version in a way that makes sense for the platform on which the merge tool runs. That means that for text files, the newline conventions must be matched; binary files must not be modified in any way. That problem is already solved, thanks to the RCS keyword expansion capability. After the versions are properly reproduced, the selected merge tool can open the file in any way it deems appropriate. BTW, the removed context of the quotation above has to do with cvswrappers, and the appropriateness of marshalling aggregate data structures in the filesystem in a CVS environment. While that is worthy of further discussion, it's not relevant to this thread. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS corrupts binary files ...
--- Forwarded mail from Greg Woods: [ On Friday, July 2, 2004 at 12:49:58 (-0700), Paul Sander wrote: ] Subject: RE: CVS corrupts binary files ... --- Forwarded mail from [EMAIL PROTECTED] [ On Wednesday, June 30, 2004 at 22:59:27 (-0700), Paul Sander wrote: ] Subject: RE: CVS corrupts binary files ... (A) they're not sources -- they're intermediate product files. They're not intermediate product files unless they can be reproduced from some other source using an established process. Yes, they are intermediate product files. Just because their ultimate source code is managed by someone else doesn't change the fact that they are not sources for the local project -- indeed it only confirms it. In other words, you're trying to integrate your vendor's CM process into some global, all-encompassing process that also happens to include yours? Oh, come on now Paul! How much detail do I have to give you? I thought you had enough experience with SCM by now that you'd understand how to manage third party components with the appropriate tools! I know how absurd it sounded, but I had to ask to make sure I understood what you were saying. And you really aren't making a lot of sense. NO, I am not even suggesting that the vendor's CM process be accounted for in any way. Whew! That's good! I'm saying quite simply that intermediate product files are what they are regardless of who produces them. Intermediate product files are things like .o files, which are neither sources nor shippables, but are an essential part of the overall build process. Because they can be rebuilt at will from existing sources using a repeatable procedure, their retention is not required and sometimes is not even desirable. This appears to be the basis of our disagreement: For me, intermediate product files, as I've defined them above, can be deleted and rebuilt at will. Products that come from outside sources do not fit this description. Because products from outside sources, for all intents and purposes, cannot be re-created without human intervention, they require an archival method that can re-create any coherent sets files supplied by the vendor at any time. That's precisely what version control is good for, and that's why I check in everything I receive from any vendor. By using CVS as my only version control tool, I don't need variants of all of my other tools that interface to version control. Additionally, my build processes manage storage and baseline references automatically, and they provide a consistent interface at the top level to facilitate automated scheduling. That means that whatever build and installation procedures that exist must have a consistent interface. In my case, I have a limited set of hooks to allow for per-build refinements (e.g. a Gnu compatible makefile in the top of the source tree that implements an all target) and also publishes its outputs (e.g. search paths for use by other builds, packing lists and shippables, etc.). In this environment, it is *possible* to hand-craft baseline builds for third-party products (as you suggest), but it is **far easier** (in the long run) to treat them like source code because all of the power of the existing environment is brought to bear to manage them. If you don't know how to track the components of your software using your own processes, i.e. over and above and outside of CVS, then I've got to wonder if you have any SCM outside of CVS. Remember CVS is not a complete configuration management system. I know you know that but I seem to have to keep pointing it out to you almost continuously. My processes track all of the inputs to my processes. They also track artifacts that are automatically managed (e.g. baseline references), as well as artifacts that can't be controlled (e.g. the operating system and patch level on the build machine). It turns out that, although such traceability records are outputs of my build procedures, they represent sources that cannot be automatically reproduced exactly, so they are also checked in and become input to the tools that reproduce old builds. Well, in my world, there are boxes around my process and my vendors. You've got to learn to think outside your box! (and especially to think outside of the box CVS works within) The power convenience given to me by the contents of the box makes compelling reason to stay inside it. Although the interfaces are fixed, they are pretty generic. Thin abstraction layers provide sufficient flexibility to accomodate the requirements of vendor-supplied files while still meeting the repeatability and reproducibility (build and configure it the same way, over and over again) requirements. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: binary files bad idea? why?
--- Forwarded mail from Greg Woods: [ On Friday, July 2, 2004 at 22:25:27 (-0400), Eric wrote: ] Subject: RE: binary files bad idea? why? At 2:11 PM -0400 7/2/04, Greg A. Woods wrote: Why is it so damn hard for everyone to keep this simple fact in mind? Because it is entirely possible to use CVS in a manner where this simply isn't an issue. Ah ha! So, we finally get back around to this issue! What a long trip it has been! ;-) Now if you remember what I stated at the beginning then you'll realize just exactly why what you've said above is the wrong answer. Don't put binary files into CVS and expect it to work 100%. CVS cannot detect and manage changes in any meaningful way in files that are not organized as lines of text, In CVS' current implementation, this is true. But it is possible to generalize it to support other data types if it can be taught something about the structure of the files it manages. One easy way to do this is to integrate type-specific diff and merge tools that are applied to reconstructed versions of sources. and many of the most common and most important delta management operations that CVS does involve three-way merges of deltas with the hope and expectation of avoiding conflicts in those merges. But this is false no matter how you look at it. Remember that a delta is a specific set of changes that derive one complete version from its immediate predecessor (or in the case of an RCS trunk, its immediate successor). Neither RCS nor CVS use deltas directly in their user-exposed diff and merge features. Instead, they reconstruct entire versions and apply the diff and merge tools to those. There's a reason for this, and the implementation is correct. (It so happens that RCS and CVS use a particular diff tool to create deltas, and they obviously know how to accumulate the deltas to reconstruct specific versions. But those algorithms are for all intents and purposes hidden from the user. At least, they are if the user doesn't review the contents of the repository directly, which is strongly discouraged anyway.) One seldom-changing binary file in a large project (e.g. thevery few found in all of the NetBSD source tree) isn't an issue provided the human management of the project contributors keeps a sharp eye out for problems with these files (e.g. through peer pressure in the NetBSD group, combined with the fact that most/all of those binary files are owned by one developer). However the more binary files your project has, the more times they are changed, the more diverse the working directory hosts, then the more problems binary files will cause if they are committed to a CVS repository. Putting binary files in CVS is a bad idea, always was, and always will be. I.e. unless you have extremely pressing reasons for including binary files in your repository (e.g. as in NetBSD they are very rare and extremely stable and owned by one developer and because NetBSD also strives to use CVS as a source distribution tool), then it's best to use other tools and procedures for managing your binary files outside of CVS. Again, this is all true if the contents of the binary files are opaque. The nature of the binary data that are part of the NetBSD sources appears to be of this nature. But you continue to ignore the situations where the binary files have structure and therefore can be differenced and merged with appropriate tools. Don't put binary files into CVS and expect it to work 100%. For unstructured binary files, this is true. For structured binary files that have effective differencing and merge tools, fix CVS so that it will work 100%. Use the most appropriate tools for the job. We are, but we want them to be better. CVS is not a complete software configuration management system. Nobody's asking it to be. It does version control nothing more and nothing less. Furthermore, CVS does provide some facilities to use it in a non-concurrent manner adding further protections. No, not really -- some of what's there doesn't work right and the rest is a bunch of half-baked add-on hacks that don't meld with the design or goals of CVS and which, as proven by this ever repeating cycle of discussion, causes more confusion and more headaches to naive users than could ever be made back in long-term benefits to anyone. I assume you're talking about cvswrappers here. True, it's a partial solution, but the marshalling capability it supplies for managing aggregate data types is appropriate. Unfortunately, no one has thought the problem through sufficiently to produce a good general solution. On the other hand, features like the modules database (and especially the Checkin.prog file capability built into it), the vendor branch, the history file, and certain other features are much more broken than support for binary files. --- End of forwarded message from [EMAIL PROTECTED]
RE: binary files bad idea? why?
--- Forwarded mail from Greg Woods: It is literally _impossible_ to manually resolve (with any degree of correctness) any three way merge with conflicts in any ``binary'' file, regardless of whether it has been encoded as text or not. It IS possible, using a tools that understand the content of the file. Data that contain record or linked structures can be merged, regardless of whether they live in memory or in files. The catch is that a specialized merge tool is needed, which doesn't happen to be based on the generic Unix diff tools. Consider the following hypothetical case: A threaded data structure is marshalled into a line-based textual format. You could theoretically use diff3 to perform a 3-way merge on the data, but then the result must be inspected and the links properly reconnected by hand. After sufficient user outcry, the vendor supplies validity checker that users can run after they complete their manual merges. Of course, the users complain that the checker isn't sufficient, so the vendor supplies a merge tool that produces usable output. Finally, the users are happy. Now consider that same case, except that the file format isn't a line-based textual format, but is instead a binary format that is less expensive to produce and consume. There's no practical difference, despite the fact that one file is binary, and the other is not. This situation occurs in real life. Frame Maker is my canonical example, because it truly does have semantically equivalent binary and text-based file formats. And there are others. (Even without concurrency there's still the issue of merging changes between branches.) (Yes conflicts can be ``resolved'' by choosing one or the other, but that's a special case, and a hack, not the general case.) Actually, it's the most general case (it will work with ANY form of data), but it's also the choice of last resort because it offers the least control over the result. (Splitting hairs here.) --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS corrupts binary files ...
--- Forwarded mail from [EMAIL PROTECTED] [ On Wednesday, June 30, 2004 at 22:59:27 (-0700), Paul Sander wrote: ] Subject: RE: CVS corrupts binary files ... (A) they're not sources -- they're intermediate product files. They're not intermediate product files unless they can be reproduced from some other source using an established process. Yes, they are intermediate product files. Just because their ultimate source code is managed by someone else doesn't change the fact that they are not sources for the local project -- indeed it only confirms it. In other words, you're trying to integrate your vendor's CM process into some global, all-encompassing process that also happens to include yours? Well, in my world, there are boxes around my process and my vendors. The boxes have well-defined inputs and outputs, and anything in my box is subject to my process. And artifacts that can't be derived from other artifacts automatically are treated like sources. And rightly so. The established process is to repeat whatever process you did to get a copy of those intermediate product files in the first place! What's so bloody hard to understand about this? It's extremely basic!!! So, what you're proposing is to use the vendor's distribution media and an offline archival system for version control, and a written installation procedure to put it somewhere (hoping that whatever local configuration options get used once are repeated next time), and assuming that the installation procedure provides a hook so that you can manage your installations as baselines? And you re-install by hand and patch for every bug fix? Yeah. Right. Get real. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS corrupts binary files ...
--- Forwarded mail from [EMAIL PROTECTED] [ On Monday, June 28, 2004 at 18:31:58 (-0700), Paul Sander wrote: ] Subject: RE: CVS corrupts binary files ... On three separate occasions, Greg actually *recommends* intalling and treating such code drops as uncontrolled sources! Paul, please stop mirepresenting what I have said. (A) they're not sources -- they're intermediate product files. They're not intermediate product files unless they can be reproduced from some other source using an established process. The code drops we're discussing come from outside and are the definitive *sources* of the data that they contain, and can't change (or be recovered if lost) without human intervention. By definition, they are source files. (B) installing third-party intermediate files on the build systems doesn't mean they are uncontrolled -- only in _your_ mind could that be true. They are, if there's no control over them. Simply installing them is not controlling them. If you can't control them, then you must remember all aspects that you can measure. If you don't then something will break as a result an uncontrolled change being introduced, and the problem will be potentially very hard to detect, correct, and prevent in the future. Dropping stuff in a directory and pointing makefiles at it is just plain bad CM. Indeed it would be, if that was all one did. In all of the articles posted so far on this thread, you have suggested nothing more. What do you have in mind, in addition to what you've said? Let me repeat again since you obviously don't grasp the full and deep meaning of this statement: CVS is _NOT_ a _complete_ software configuration management system. READ MY KEYS: I agree that CVS is not a complete software configuration system. In the very message that you snipped above, I listed a number of things that must be done with files like this, starting with a tuning/build/installation/deployment method that itself undergoes good CM. CVS is used only for the version control part, archiving the incoming sources and providing a convenient extraction method that happens to be the same one that tracks all other sources in the product. Obviosly anyone interested in good SCM will have external procedures to account for these third-party files, just as they should have procedures for dealing with _all_ attributes of their build environment. Cool. We agree on something. It's good when you say what you mean. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
--- Forwarded mail from [EMAIL PROTECTED] [ On Monday, June 28, 2004 at 19:02:19 (-0700), Paul Sander wrote: ] Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...) I have never, ever advocated changing the format of an RCS file in a way that would break the ci, co, rcs, or rlog programs. And although I strongly advocate the replacement of user-exposed diff and merge tools, I have never, ever advocated the replacement of the diff tool that computes the deltas stored in an RCS file. Indeed -- instead you would rather use different algorithms for storing deltas and for using them. That would be just plain stupid, if indeed not eventually dangerous to the integrity of a repository. What are you talking about? I can think of only two ways that CVS uses the deltas: Reconstructing complete versions, and annotating version history. For the purposes of this thread, which started out with diffing and merging files, the tools require reconstructed versions. Of course, the algorithms that produce the deltas and reconstruct the original data must agree. But that's all below the RCS API and is completely invisible to the user. Once the user has two or three complete files, he can apply any diff or merge algorithm he wants to those files. Recall the following sequence of operations: co -pancestor file,v a co -pcontributor file,v c diff3 -E file a c Once again, the algorithms and data formats that maintain the integrity of the RCS files is hidden away and invisible to the user by way of the co and ci programs. The user can replace the invocation of diff3 with any tool that he chooses to perform the content merge. Once done, the user uses ci to produce a new delta in the RCS files, using the very algorithm that produces the correct data for subsequent invocations of co. There's absolutely no danger to the integrity of the RCS file, unless someone mucks with the innards of co or ci. And nobody is even hinting that making such changes is desirable, at least with respect to the deltatext phrases in the RCS files. (There have been several recommendations to exploit the areas of the rcsfile format that explicitly permit extensions, but extensions of this nature have absolutely no effect on RCS' ability to store and reconstruct versions, which I have demonstrated in a separate message.) The tools we now have for calculating and handling deltas are all designed to work _together_, not in isolation of each other, and that uniformity is as valuable to CVS as it is to RCS alone, if not more so. What tools, specifically (and I mean, you need to name them and include pointers to them so that the rest of us can look), are you talking about? The RCS programs and CVS in its current implementation are the obvious ones, and my comments withstand scrutiny on those. What else are you referring to? How about you go off and spend the next, say, two years or so intensively using such a scheme as you propose on a massively huge variety of projects. That should give you about 10% of the experience the rest of the world has with using diff and diff3 and rcsmerge uniformly for both purposes. Then if you still think it's wise to use disparate techniques for storing deltas and for using deltas then you can show your results and raise your proposal here again. In the mean time please keep in mind that there are not just a plethora of tools for using diff-style deltas, but there's also an enormous amount of human experience with them too. I look forward to seeing your list of references, so that we can debate the relative value of interpreting ed-like scripts for a least-common denominator level of functionality, versus parsing the entire content of a reconstructed file and applying domain-specific algorithms that understand the type of data stored there. You (and a few others) seem to want to throw the baby out with the bath water, and all just so that a few hair-brained and lame mis-uses of CVS will work better. In the mean time if you (and others) had learned to use the best tool for the job in the first place then you'd never have had to dream up such a half-baked idea. CVS has a notoriously poor diff and merge capability. Integrating the user-exposed features with better tools is a very good example of using the best tool for the job. And it's not a half-baked idea; the whole idea of plug-ins is well established in the industry, and its feasibility in CVS is proven. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
--- Forwarded mail from [EMAIL PROTECTED] [ On Monday, June 28, 2004 at 14:58:03 (-0700), Mark D. Baushke wrote: ] Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...) Yes, but diff is not diff3. diff is used for the delta format. diff3 is used by rcsmerge, not for fundamental version deltas. I think you're confused -- the differencing algorithms used are fudamentally intertwined (and fundamentally based on units of lines of text). This true, insofar as to maintain the integrity of the RCS files and to reconstruct complete versions. Pretending you can do merges using some other algorithm while still trying to store your deltas in unix diff format is just leading everyone down the garden path to a dark dank corner no-one really wants to be in. What do we care what format the versions are stored in, as long as we can recover the complete files and apply any tool we want to them? Although I can imagine such a thing, I don't know of any merge tool reads the ed-like scripts produced by the diff program and presents a user interface to apply or omit specific deltas to an input file. It's an interesting idea, and it might even be useful, but its utility is limited. On the other hand, reconstructing entire versions and applying content-specific tools is far more useful. For example, there is research on hierarchical differencing algorithms that compare tree-like structures like the ones produced by parsers of programming languages. I foresee that this will lead to a new wave of merge tools that provide a much higher level of utility than line-based tools like diff3. This kind of work just isn't possible with line-based deltas produced by the diff program. (It's also possible that they could lead to a new wave of archivers that provide RCS-like capability but use the hierarchical diffs in the deltatext records, which will be interesting. But nobody's suggesting a possible replacement of the RCS layer just yet.) The uniform use of differencing algorithms and their corresponding merge algorithms (which are of course just editing scripts), is what makes it worthwhile to use something like RCS as the foundation for CVS in the first place. It's what makes it possible for systems like RCS to exploit the similarity of sequential versions for efficient storage, to be sure. But applying a delta to reconstruct a version is very different from doing a content merge of two or three fully reconstructed files. I.e. it is not sufficient to just use the RCS delta format as a means of archive compression -- that format is integral to the whole idea of detecting, reporting, and merging, changes in any RCS-compatible tool. Once again, no one is suggesting changing the way that RCS works. Are there really utilities out there that try to to read RCS formats directly and do not allow for rcsfile(5) syntax to be used? If so, could you name any of them? Humans, for one. :-) (I know some folks can do manual merges of SCCS files, and though the same techniques won't work quite so well on RCS files because of the reverse delta thing, there are still a great many other valid reasons to read and even repair RCS files by hand.) There are a number of commercial software pacakges which are GNU RCS compatible, apparently without using RCS source code, with the most popular perhaps being CS-RCS (though I've not confirmed 100% that it does not use RCS source code). SourceCodeManager is apparently another, and P4D yet another. Perforce also uses RCS compatible files as its archive format, but I'm not sure if its core RCS handling was derived from RCS source code or not. I think I've just scratched the surface too, if any of the rumours I've heard are close to true. Well, if these tools are truly RCS compatible then they should be able to ignore the newphrases we've been talking about. And since there is no proposition to change the format of the deltatext phrases, or any of the other standard components of an RCS file, those tools should continue to work. BTW, I have also written a couple of tools that parse the RCS file syntax. They conform to the rcsfile format and should tolerate extensions made as newphrases as specified. I have also seen commercial tools derived from RCS (specifically, the MKS variety) that have made proprietary extensions and are no longer compatible with the Gnu standard. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
--- Forwarded mail from [EMAIL PROTECTED] Mark, I agree with your response to Greg's claims about RCS compatibility, or the lack thereof. In particular, I am not aware of any fundamental problems rcs 5.7 will have if someone were to introduce a new keyword which would name a program other than diff3 to be used in rcsmerge operations. At most, I would expect a warning message via the warnignore() function which would specify co: file,v: warning: Unknown phrases like `diff3hint ...;' are present. and even so, a 'co -q file,v' would not generate such a message. So, I believe that adding a 'diff3hint someprogram;' line to the RCS file should not be a problem for co to still be able to checkout each and every version of the file. Rather than use a hint to expose an implementation detail, I suggest recording a data type instead. Maybe even a MIME type. Then provide a suitable mechanism to map data types to tools that are appropriate to the environment. BTW, CVS no longer uses rcsmerge; it co's the necessary versions and runs diff3 directly. So in a CVS context, pushing this capability down to RCS isn't really a requirement. However, I recognize the usefulness of doing so, and would not oppose such a feature. On the other hand, doing so will likely be a duplication of effort because CVS has client/server concerns that RCS does not, and that may necessitate a different implementation. Given that this would appear to be the desire of at least a few folks out there who might want to make CVS do a better job at merging structured ASCII files such as XML or HTML format. And further, that you seem to have objections to this approach. And while I have known you to bring up points I have overlooked in the past... Not just structured ASCII files as you describe, but any file containing structured data for which a merge tool is available. This time around I just do not see anything that would preclude such an approach of using an external diff3 hint 'replacement' program for doing a 'cvs update -jtag1 -jtag2' operation. I will stipulate that such a program will likely need to live on the server and furthermore that it would not be interactive. In the absense of finding such a program, CVS would likely resort to using diff3 as a fallback, so its arguments would likely need to match those of the diff3 program itself... at least to the extent that cvs currently uses various arguments to diff3. I don't believe that such a program MUST live on the server. Merge tools, like editors, have a way of becoming religious icons, in situations where users have a choice. Under such circumstances, it becomes important to have client side mappings between data types and merge tools. Additionally, I don't believe that merge tools necessarily need to be fully automated. After the relevant versions have been downloaded to the client (and the repository locks have been cleared), the merge tools can run interactively. However, I believe that CVS current intersperses merges with downloads, and that would need to change before interactive merges can be supported. Also, CVS currently relies on diff3-style mark-ups to warn the user when merge conflicts remain present at commit time. Though strictly speaking such warnings are not necessary, they are incredibly useful. And they'll be lost unless merge conflicts are recorded another way. One way is to lists conflicts in a file stored in the CVS directory. At commit time, skip the scan for diff3 mark-ups and instead read the conflict list and compare mod times of the relevant files. If they have changed, assume the conflicts have been resolved. Let me state the scope of the thought experiment: Goal: Provide a means whereby a cvs administrator may cause a program other than diff3 to be used when doing merge operations as a part of a three-way merge of files in a sandbox. This program might be defined as a keyword used as the value of a 'diff3hint' followed by an 'id' which could be looked up in a table that cvs could keep to determine which executable and any additional arguments above the diff3 form arguments might be required. Again, I think that recording a data type is a more straightforward (or at least more easily understood) implementation. Assertion: The diff3 replacement must handle all of the args that cvs normally passes to diff3. Yes. Assertion: The diff3 replacement must not be interactive in nature for client/server repository uses. Well, okay for the first implementation. :-) Assertion: The diff3 replacement must be able to run just given the three versions of the file without any other state. Yes, but it would be nice to be able to pass in the version numbers for column headings or the like, if the tool permits. Assertion: That cvs continue to write new RCS files in adherence to the syntax defined in rcsfile(5), but allowing the introduction of one or more new phrases and associated id word values as allowed for by the RCS format syntax.
Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
--- Forwarded mail from [EMAIL PROTECTED] [ On Monday, June 28, 2004 at 01:44:36 (-0700), Mark D. Baushke wrote: ] Subject: Re: Smoke, FUD (was Re: CVS corrupts binary files ...) The RCS format is very extensible and in fact the CVSNT folks have extended it already and I have had no problems using CVSNT repositories in conjunction with either CVS or RCS. very is an over-statement of the first order! ;-) Sure, it's an extensible format, but not in the way that's been suggested. You can't get rid of the _exclusive_ use of diff et al without entirely losing compatabilty with RCS. Nobody has suggested abandoning diff for computing RCS deltas. All discussion relating to replacement of diff and merge tools have revolved around the user interface. That's completely different. I do not see support for your assertion that compatibility is far more than just the adherence to the syntax defined in rcsfile(5). Sadly rcsfile(5) only describes the meta-syntax, not the nutsbolts of how RCS files work and how they're actually used by the RCS package. So, I believe that adding a 'diff3hint someprogram;' line to the RCS file should not be a problem for co to still be able to checkout each and every version of the file. diff3hint in the way you're hinting it might be used is insufficient. RCS directly interprets the content of the delta text information, e.g. the likes of: @d5 1 a5 1 some new line of text d256 1 @ See, for example, lib/rcsedit.c from the RCS source distribution. You are obviously missing something here. We're talking about adding a newphrase in the admin, delta, or deltatext productions. Using the deltatext production and your diff output as an example: 1.1 log @this is a log message @ diff3hint use-this-tool; text @d5 1 a5 1 some new line of text d256 1 @ This obviously extends the RCS file format in a way that does not break compatibility with the existing RCS software. Following is a complete RCS file that contains not one but three extensions, but they're done in a way that is supported by the RCS file format. And none of the RCS programmatic interfaces break. head1.4; access; symbols; locks; strict; comment @# @; admin-ext @this is an admin extension.@; 1.4 date2004.06.29.09.08.54;author paul;state Exp; branches; next1.3; 1.3 date2004.06.29.09.05.20;author paul;state Exp; branches; next1.2; delta-ext @this is a delta extension.@; 1.2 date2004.06.29.09.04.53;author paul;state Exp; branches; next1.1; 1.1 date2004.06.29.09.04.24;author paul;state Exp; branches; next; desc @Test file. @ 1.4 log @Added the beep! @ text @This is a test. This is only a test. If this had been an actual emergency, it would have been too late. BEP! @ 1.3 log @Done! @ deltatext-ext @this is a deltatext extension.@; text @d4 1 @ 1.2 log @First change. Needs more work. @ text @d3 1 @ 1.1 log @Initial revision @ text @d2 1 @ Any modification of the diff algorithm would almost certainly require changes to the syntax of this delta text. Actually, this isn't true. The diff program itself implements multiple algorithms. But that's neither here nor there because nobody is recommending that the format of the differences be changed. As far as I can tell the extensibility of the RCS,v syntax does not go so far as to provide for callouts to add-on programs and I'm arguing that it's _far_ too late to try to modify this widely used standard file format now. It's never too late to update a standard. In any case, RCS file extensibility has been in the standard for a very long time now. So, how _exactly_ do you propose to convince the standard co program (or the equivalent in any other RCS-compatible tool suite, including the current CVS implementations) to actually make use of the new delta text syntax that such a hack would create? I.e. How do you propose to make it possible for the standard RCS tools alone to re-create _every_ revision from all files created by this hacked system? Simple: The delta text would not change. See above. It's simply not possible. Like I said, only the bare surface of RCS compatability is scratched by the meta-syntax described in rcsfile(5). Absolutely untrue, as demonstrated by the RCS file above. The RCS file format is intricately intertwined with the unix diff algorithm, which is itself tightly dependent on the normal use of lines of text to represent elements of a the source files being managed This much is true. (at least when it comes to automated merging for concurrent editing). But that is not. The diff and merge algorithms that the user applies are distinct from the diff algorithm that computes the deltas. They can be changed, as I've demonstrated before on several occasions. It so happens that the rcsdiff and rcsmerge programs, and CVS itself, use the same programs forr both purposes, but there is no technical
Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
--- Forwarded mail from [EMAIL PROTECTED] Paul Sander [EMAIL PROTECTED] writes: --- Forwarded mail from [EMAIL PROTECTED] =20 Rather than use a hint to expose an implementation detail, I suggest recording a data type instead. Maybe even a MIME type. Then provide a suitable mechanism to map data types to tools that are appropriate to the environment. I have no fundamental objection to saving the MIME type. I suggest that it may need to be inside of a string to pass the syntax of rcsfile(5). I would actually suggest that it might be useful to just borrow both of the MIME media-type and charset concepts. That might allow for a=20 media-type text/plain; charset ks_c_5601-1987; on a given file... the defaults should probably be text/plain and iso-8859-1 or utf-8 Do you propose that the media-type be valid on its own, for data types where charsets have no meaning? Or put another way, is the charset solely to provide additional processing hints to supplement the media-type, or is the charset also required? Given that this would appear to be the desire of at least a few folks out there who might want to make CVS do a better job at merging structured ASCII files such as XML or HTML format. And further, that you seem to have objections to this approach. And while I have known you to bring up points I have overlooked in the past... =20 Not just structured ASCII files as you describe, but any file containing structured data for which a merge tool is available. Ahh, but I am not really trying to suggest that binary files are suitable in the general case for CVS control. That is a separate argument. Fair enough, but the practice is more common than anyone wants to admit. The issue must be faced at some point. That said, I suppose that a merge utility that understands how to merge a file containing lines in a non-ISO-LATIN character set might also fall into the category of a diff3 replacement and that such files might be considered 'binary' by some programs. Indeed. This time around I just do not see anything that would preclude such an approach of using an external diff3 hint 'replacement' program for doing a 'cvs update -jtag1 -jtag2' operation. =20 I will stipulate that such a program will likely need to live on the server and furthermore that it would not be interactive. In the absense of finding such a program, CVS would likely resort to using diff3 as a fallback, so its arguments would likely need to match those of the diff3 program itself... at least to the extent that cvs currently uses various arguments to diff3. =20 I don't believe that such a program MUST live on the server. The changes needed to allow the client-side to do a merge are very large. I am not willing to stipulate an implementation that would allow CVS to deal with an interactive merge operation for a random 'cvs update' command. The repository would have a lock open for too long in that case. Yes, to avoid long-lived locks, the necessary files must be copied to the client before the merge begins. This would involve a significant change to the client, but I'm not convinced that it would be a significant change to the server. The server already has the ability to send whole revisions to the client, and it need not be involved with the merge once it starts. Merge tools, like editors, have a way of becoming religious icons, in situations where users have a choice. Under such circumstances, it becomes important to have client side mappings between data types and merge tools. Your arguments almost help to make a case in Greg's favor against allowing a diff3 replacement. Horrors! I sure hope not! :-) The kind of flexibility you desire is not something that I think makes sense to bolt into the 'diff3' slot. Then bolt in a wrapper that reads the user's environment and invokes a suitable merge tool based on preferences that are found there. And provide a default, like diff3, if such information is missing. What you propose would potentially best be handled with an entirely new kind of update paradigm. Possibly the use of a CVS/Base/file file and a 'patch' that would bring CVS/Base/file up to the latest version would be 'better' in this case... Whatever's most efficient to get the other contributor and common ancestor to the client. Clean-up needs to be considered as well. Additionally, I don't believe that merge tools necessarily need to be fully automated. Here we do not agree. Without such automation, lock contention on directories could get very intense. Again, running the merge after relevant data have been copied out and freeing the locks would remove this issue. Actually, the ancestor and contributor are checked-in versions, and they're known in advance either by version number or branch/timestamp. Correct me if I'm wrong here. If this really is true, then directory locks aren't even needed in the repository. This specific issue has been discussed in this forum once before
RE: CVS corrupts binary files ...
--- Forwarded mail from [EMAIL PROTECTED] [ On Monday, June 28, 2004 at 11:00:23 (-0400), Jim.Hyslop wrote: ] Subject: RE: CVS corrupts binary files ... Any manual procedure is prone to error. I prefer to automate things as much as possible, to minimize the possibility of human error. Any time I see a manual process, I wonder how it could be automated. While I will agree in part, I'll also point out that even NASA sill uses paper checklists. :-) I know people who work for NASA, and I know people who have worked for NASA in the past. They have a saying at NASA: It was good enough to get us to the moon, so it's good enough for this. Twenty years ago, they really meant it. When you speak about how great NASA is and mention the antiquity of some of their processes, remember that the paper checklists have since contributed to the failure of several missions (some of which missed entire planets) and the loss of 14 lives. Also remember that a modern wristwatch carries more computing power than the spacecraft that orbited and landed on the moon, and a modern cell phone has more computing power than the whole of NASA had in those days. In a time when mission critical software was only hundreds or a few thousands of bytes in size, it could be managed with paper checklists. Today that is no longer the case, at least not unless you're willing to tolerate a much higher level of risk. So NASA is learning that what worked well in the past may not necessarily work well in the future, maybe not even today. Reliability is the order of the day, and it turns out that reliability of a given procedure varies inversely with the number of fingers poking it. And today that saying is spoken in jest. Perhaps it would be instructive for those grappling with the complexities of build systems, and version control integration, and other components of a complete software configuration management system to examine the likes of NetBSD's build system. NetBSD is awesome! But keep in mind that the reason they can do what they do is that they literally own the entire environment, from the OS and system libraries on up. Yes, they have to build cross environments, but after they've built the cross compiler twice the runtime environment of the build system really doesn't matter as long it can schedule CPU time and access files. Most of us don't have that luxury. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS corrupts binary files ...
--- Forwarded mail from [EMAIL PROTECTED] [ On Thursday, June 17, 2004 at 15:49:39 (-0700), Paul Sander wrote: ] Subject: RE: CVS corrupts binary files ... Nope, I got it. The thing is, you can control pointers (e.g. makefiles containing references to files stored in a library somewhere) all you want, but that buys you nothing unless the targets of the pointers are also tightly controlled. No, you didn't get it. You seem to be among the many people who always forget to keep in mind what CVS is _not_. For example: CVS is not a complete software configuration management system. You are correct: CVS is a version control system. And it does version control only. That means that it archives collections of files for later reproducibility as a set (by label or branch/timestamp) or individually. And it does so without regard to the content of the files, though it works best with files that contain only ASCII text. What CVS does NOT do includes but is not limited to the following: Compiling or building software from sources (i.e. build procedure); packaging, installing, configuring, or deploying software produced by a build procedure; passing collections of versions around and tracking their progress through the development process (i.e. change control). Furthermore, all of these must be repeatable procedures that produce identical results when given identical inputs (or if not bit-for-bit identical results then at least bug-for-bug compatible results), and as output they must also record all inputs and outputs so that specific results can be reproduced at will. That means that the procedures must remember environment variable settings, command line parameters, baseline references, profiling and debugging flags, the operating system version and patch level (and sometimes even the hardware configuration), and a bazillion other things in such a way that they're readily available so that someone can either a) run a procedure that's identical to another one but with one or more specific and controlled variations, or b) reproduce the results of a past build exactly. And if a procedure fails for some reason (e.g. dangling baseline pointer or OS incompatibility) then it must diagnose the reason so that humans can perform the necessary recovery. Anyone using CVS as a change tracking tool _must_ have some encompassing software configuration management system as well. If that encompassing SCM system does not have tight control over _all_ of the components and procedures and processes used in the production of the software products then it is certainly not the fault of CVS. This much is true, also. Version control is not sufficient on its own to build a good SCM system. All of the pieces I listed above that CVS does NOT do are also necessary components. Some of these pieces are readily available, and others must be built. However, getting back to the issue that originated this thread, there remains the question of what to do with code drops from external sources (particularly drops that are delivered in binary form). I maintain that such code drops must be handled as any other sources: Put them under source control, and apply the necessary change, build, and deployment procedures to treat it like any other part of the product. Contrast this with Greg's recommendations, which I reproduce here: ++ From: Greg A. Woods ++ Subject:Re: CVS corrupts binary files ... ++ Date: Tue, 8 Jun 2004 17:15:29 -0400 (EDT) ++ [ On Saturday, June 5, 2004 at 13:01:48 (-0700), Adrian Constantin wrote: ] ++ Subject: Re: CVS corrupts binary files ... ++ ++ I don't wanna merge binary files, and I'm not likely ++ to modify them in my module (project). I just want cvs ++ to carry them along with the sources ++ Then your better tool is called a directory (i.e. outside of CVS) and ++ you use it with a simple reference to it from within your build system. ++ -- ++ Greg A. Woods and here: ++ From: Greg A. Woods ++ Subject:Re: CVS corrupts binary files ... ++ Date: Thu, 17 Jun 2004 16:12:15 -0400 (EDT) ++ [ On Wednesday, June 9, 2004 at 09:35:37 (-0400), Tom Copeland wrote: ] ++ Subject: Re: CVS corrupts binary files ... ... ++ Most of my Java projects use 3rd party jar files, ++ which are compressed tar balls, more or less. And I certainly don't ++ want to try to merge foolib-0.1.jar with foolib-0.2.jar when a new ++ version comes out; I just want to put it in CVS so that it gets tagged ++ and exported and so forth. ++ No, you REALLY DO NOT want (or need) to do that. What a waste. ++ What you should do is treat the foolib product files for what they are ++ and to install them as products on your build machines in directories ++ named after their complete version-specific identifiers. ++ Then you need only program your build system to refer to the appropriate ++ directory for the appropriate components and if your build
Re: Smoke, FUD (was Re: CVS corrupts binary files ...)
--- Forwarded mail from Greg Woods: [ On Thursday, June 17, 2004 at 16:49:42 (-0700), Paul Sander wrote: ] Subject: Smoke, FUD (was Re: CVS corrupts binary files ...) If this is true, then we're in violent agreement. But to date, you have argued that making the necessary changes to CVS to give better support for data types not handled well specifically by the diff and diff3 programs would break compatibility with RCS, which is demonstrably false. Have you not looked at the content of an RCS file lately Paul? RCS compatability is far more than just the adherence to the syntax defined in rcsfile(5). If the generic co program from the RCS package cannot extract any and every revision of a file from a file claiming to be an RCS file then that file is clearly not RCS compatible. I have never, ever advocated changing the format of an RCS file in a way that would break the ci, co, rcs, or rlog programs. And although I strongly advocate the replacement of user-exposed diff and merge tools, I have never, ever advocated the replacement of the diff tool that computes the deltas stored in an RCS file. (That is not to say that I have never suggested making incompatible changes, but in context such suggestions have always carried caveats and recognized the lack of desirability of losing a valuable feature.) I don't know where you seem to be getting the idea that I'm recommending doing a global search and replace of diff with some other tool. That is clearly not the case. The RCS file format must be retained, unless we as a group decide to abandon it after weighing the consequences. However, I do advocate extending the RCS file format in ways that the RCS API can accomodate. The rcsfile(5) manual specifically allows for extensions in the admin and delta sections of the file. For example, I do recommend using a newphrase in the admin section to identify the type of data stored in the file, but not until the rename problem is solved. How am I spreading Fear, Uncertainty, or Doubt? Maybe hypocrisy would be a better description of your approach to CVS. I don't believe I'm misrepresenting any of my beliefs about CVS or SCM in general. I've tried very hard to explain them clearly, and I've tried especially hard to drill them into that rock that you carry on your shoulders, but I'm obviously using the wrong screwdriver. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: branch removal question
Normally one would apply a tag to the versions that are ready for testing, and update the tag as bugs are fixed. Then apply a second tag to the code that reaches production quality. To apply the second tag, use the cvs rtag -r option. The bummer with this is that if you make bug fixes in your test environment, you must run an additional cvs update command on each modified file due to stickiness issues in with the tags, but it's a minor annoyance that's overcome with experience. And you must remember to apply the testing tag to the committed fixes, a part of the process that might easily be forgotten. --- Forwarded mail from [EMAIL PROTECTED] I asked this question last Friday but got no response. Was it poorly asked, not enough information, too ignorant for words? If I need to supply more information please let me know, I would be glad to. -Original Message- From: Don Butts [mailto:[EMAIL PROTECTED] Sent: Friday, June 18, 2004 9:45 AM To: [EMAIL PROTECTED] Subject: branch removal question We are using cvs in somewhat of a non-standard way. We have a production cut of our compiled source that we deploy via cvs using a production branch. The application does not mind the fact the CVS control files co-exist within the source and the application runs fine. When we want to patch production we first patch the same branch in a different checkout area and then commit it. When it comes time to upgrade the production area we bring down the application during a maintenance window and perform a cvs update in the production area. This has worked great for more than a year so I am very happy with this process. We were basically mimicking this process in a pre-production area for QA purposes and while this has worked OK we are having a bit of trouble keeping these two branches in sync. So, I know that I can remove a branch via the cvs admin -n command and I am wondering if a better process would be to remove the preprod branch every time I move a new patch to production and when it comes time to test the next patch just recreate the preprod branch off of the current prod branch. I have performed some tests using this method and all seems to work fine but I thought that I would ask the opinion of those who have been using CVS a lot longer than I. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: branch removal question
--- Forwarded mail from [EMAIL PROTECTED] Don Butts wrote: I asked this question last Friday but got no response. Was it poorly asked, not enough information, too ignorant for words? I wouldn't remove the branches. I'm always reluctant to remove anything from the history. Instead of checking out branches, it might be easier to apply non-branch tags instead. This means fewer branches to deal with. I'm guessing the reason you're using a branch is because the update command remains the same, e.g. cvs update -r PROD (where PROD is a branch tag). Basically, what you would do is to create a non-branch tag indicating the currently-tested and working version, e.g. cvs tag REL_2_0_2. Then, you can move the PRODUCTION tag using the -F option to tag. Floating tags can also be used. For example, create a tag called PRODUCTION and apply it to the next release. Then just run cvs update in the production area, and the proper versions will appear. The down side to this is that if you don't apply unique tags in addition to the floating one, you can't go back if something breaks. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Undoing renaming a directory
--- Forwarded mail from [EMAIL PROTECTED] Jean-Christian Imbeault wrote: One of our developers just checked in new code (more than once) and by mistake renamed a directory from src to source. Is there a simple way to undo this? I've been reading the archives and it seems that there isn't ... Um, is it too obvious to suggest renaming 'source' to 'src'? Unfortunately, none of the recommended (or documented) workarounds for cvs' absence of a true rename is reversible without either losing something or having to do a lot to recover the entire history of the configuration. If nothing was checked into the new source tree (the original mail suggested that the time period was brief between doing the rename and deciding that doing it was wrong), then just stop using the new source tree and re-add the original src tree. If changes were committed, then diff and patch will become your best friends. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Why should you want to remove sticky tags?
I think there are two aspects to the removing sticky tags issue: - Removing tags - Removing the stickiness of tags Removing tags is desirable to clean up the output of cvs log if a lot of temporary tags are created. An example of this is when built sources are labelled after every build, and most builds (e.g. nightly builds) are disposable. Removing stickiness is desirable if you expect cvs update (without -r or -A) to bring your workspace up to date after checking out with a version tag. But this is really only true if the local process doesn't used floating tags. Using floating tags means that the tags themselves move. Doing a cvs update (without -r) brings a workspace up to date with respect to the tags, copying out the newly tagged versions. In this case, the sticky behavior is needed so that the tags aren't forgotten between updates. I personally would like to see stickiness of version tags be removed, because it's harder to bring a branch up to date in their presence than to give -r when using floating tags in the absence of stickiness. Note that this all applies to tags that identify versions, not to tags that identify branches. Branch tags really need to be sticky. --- Forwarded mail from [EMAIL PROTECTED] When I'm reading articles/guides about CVS I notice that removing sticky tags is often talked about. I don't understand why you want to remove a sticky tag. If (for example) you have files in a repository and they're ready/checked/validated for release 1, then you tag them all with rel-1-0. Why, in a further stadium, would I want to remove this tag? Or perhaps I am confused about Tags and Sticky Tags. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs merging - conflict
--- Forwarded mail from [EMAIL PROTECTED] On Thu, 17 Jun 2004, Feldmann, Rick wrote: Date: Thu, 17 Jun 2004 11:53:55 -0400 From: Feldmann, Rick [EMAIL PROTECTED] To: 'Kaz Kylheku' [EMAIL PROTECTED] Cc: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: RE: cvs merging - conflict Kaz, Thanks for the reply. Nice explanation of the differences. As for white space, I'm not asking for the machine to blindly throw white space away, I'm asking for the ability to tell the machine to throw away white space. It doesn't even have to be the default, just an option. The problem with that is that the project now has users who are deciding to use an option. So from the configuration manager's point of view, he has a machine (system + programmers) that is doing silly things. :) The whitespace truly has to not matter, no matter where it occurs. In your case, you are dealing with XML, in which whitespace does matter. Not everywhere, of course, but in some contexts, like the data itself: foo /foo is different from foo/foo foo key=value is different from foo key=value There is no telling how such differences will affect some process that uses that XML as input. All the more reason to provide a hook to insert a merge tool that is senstitive to the data type. But that's a different thread... --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
--- Forwarded mail from [EMAIL PROTECTED] [ On Tuesday, June 8, 2004 at 16:21:03 (-0700), Mark D. Baushke wrote: ] Subject: Re: CVS corrupts binary files ... It may be that the diff3 algorithm is not always the best one suited to do such mergers. That may be true, but the use of the traditional diff and diff3 algorithms for detecting and merging changes in the managed files is a direct concequence of the fact CVS is built on top of RCS and RCS has no alternative to using, and no _real_ way to specify any alternative, to these algorithms (at least not without breaking RCS compatability). Although the earliest releases of CVS used the rcsmerge program to perform merges, I think you'll agree that the following are equivalent: rcsmerge -pversion1 -pversion2 file versus: co -pversion1 temp1 co -pversion2 temp2 diff3 -E -am file temp1 temp2 Current releases of CVS do the latter. (Don't believe me? Look at the function named RCS_merge in the rcscmds.c source file.) It's a simple matter to replace the invocation of diff3 with a different tool. Given this, statements like the following do nothing but spread FUD. They are flatly false, and you would do the world a big favor if you would stop writing them. It might be desirable but it's not really possible without giving up on the use of RCS in the back-end -- or at least without giving up on backwards compatabiltiy with other RCS tools. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS corrupts binary files ...
--- Forwarded mail from [EMAIL PROTECTED] [ On Wednesday, June 9, 2004 at 09:15:24 (-0400), Jim.Hyslop wrote: ] Subject: RE: CVS corrupts binary files ... Let's not throw the baby out with the bathwater, shall we? Granted, CVS was not *originally* designed to handle binary files. Granted, CVS does not handle binary files as well as it handles mergeable text files. But even with CVS's handicaps and limitations WRT binary, CVS is still orders of magnitude better than manually maintaining versions of files in a directory. How do you figure that? A plain old directory is infinitely better at managing static content, binary or not, than _any_ versioning tool. Anything over and above a plain old directory _only_ adds unnecessary layers of complexity. I've done revision control by backup, and I've done revision control by naming convention. Both have proven to be disasters. Introducing uncontrolled sources into your process is not the answer. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
