Re: Branch Numbers

[Kaz Kylheku]

On Tue, 10 May 2005, SUBRAMANIAN, SARAVANAN (SBCSI) wrote:

> How Branch Numbers are formed Internally in CVS.
> I read the manual it is really confusing.

Branch numbers, like verison numbers, are independently assigned in
each file. As branches are sprouted from version X.Y  of some file, then
the successive even integers are chosen as the branch number, for
example, X.Y.2, X.Y.4, X.Y.6 and so on. Internally, branch numbers are
represented with an extra zero, like X.Y.0.2. 

Even integers are probably chosen to avoid clashing with vendor
branches, which are numbered by odd integers. People rarey use vendor
branches other than 1.

The DCVS software (distributed version of CVS) provides configuration
control over branch numbers as a key part of its implementation
strategy. So that branches independently created in replicated
respositories do not clash with each other, DCVS nodes are manually
configured with non-clashing ranges of branch numbers. E.g. if we
formed a DCVS network, your range might be even integers between 1000
and 1998, and my range might be 2000 to 2998.

> We have two branches, after we created the second branch, when the
> developers start committing the files,
> 
> I found out that one file is committed with 1.12.2.1
> And other with 1.1.4.1
>
> Please help me found the why there is a difference in the above?

It's possible that one of the two files simply didn't get the first
branch: perhaps the file simply didn't exist at the time that branch
was created, or was otherwise excluded in some other way. And so when
the second branch was created, the next available positive even integer
was 2 for that file. So branch number 1.12.2 was created off version
1.12. Branch number 2 was already taken in the other file, so your
symbolic branch got number 4 in that file.

In general, branch numbers will differ between files for the same
logical branch, just like version numbers differ in a set of files that
form a logical, tagged release. All of the RCS revision operations are
done independently on each file.

-- 
Meta-CVS: the working replacement for CVS that has been stable since
2002.  It versions the directory structure, symbolic links and execute
permissions. It figures out renaming on import. Plus it babysits the kids
and does light housekeeping! http://freshmeat.net/projects/mcvs



___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Odd typo in update message?

[Kaz Kylheku]

On Tue, 15 Mar 2005, Mark E. Hamilton wrote:

> Date: Tue, 15 Mar 2005 12:06:27 -0700
> From: Mark E. Hamilton <[EMAIL PROTECTED]>
> To: info-cvs@gnu.org
> Subject: Odd typo in update message?
> 
> I ran across the following typo in the output from 'cvs update', when it 
> is passed the name of a file which exists but is unknown to cvs. Note 
> the use of a grave accent on the left and an apostrophe on the right.

Opening quote, closing quote. When I'm writing e-mail, I 
quote, ``like this''. 

This is also the input convention used in the TeX typesetting system,
which turns that lexical notation into properly typeset quotes.

In some countries, opening quotes resemble commas, ,,like this''.
99 down, 99 up. Over here it is 66 and 99.

The closest thing to 66 and 99 is to use two backticks and two
apostrophes.

In some fonts, the apostrophe character ' actually looks like a tiny
number 9, but with the loop filled in, and the backquote looks just
like it but turned 180 degrees to make a tiny 6.



___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Renaming a file in the trunk but not in branches

[Kaz Kylheku]

On Fri, 11 Mar 2005, David Leskovac wrote:

> Date: Fri, 11 Mar 2005 11:27:57 -0500
> From: David Leskovac <[EMAIL PROTECTED]>
> To: info-cvs@gnu.org
> Subject: RE: Renaming a file in the trunk but not in branches
> 
> One additional question on this:
> Is there any way to preserve history on the new file?

A new file has no history to preserve. ;)

> My understanding is that if I copy the ,v to ,v
> on the server and then run the commands below on the client, then
> this will affect the trunk as well as the branches. Is this true?

Not if you edit the RCS file to ``scrub'' ,v of any branch
tags, while keeping all of the RCS delta nodes and their checking
comments intact.

> If true, is there any other way to rename a file in the trunk &
> retain the history of the oldfile in the newfile while keeping the
> oldfile intact in the branches?

Meta-CVS has true renaming. A name is a versioned property
of a file so when you rename, you are simply editing that property
while retaining the original file.

This means you can merge across renames, which is arguably more
important than merely having the history there.

You want to be able to rename something on the trunk, yet still be able
to merge someone's ongoing branch work. What if someone goes to the
release branch and fixes a bug to a file that has since been renamed to
the branch? Who's going to sit there and manually hunt down these
edits?

-- 
Meta-CVS: the working replacement for CVS that has been stable since
2002.  It versions the directory structure, symbolic links and execute
permissions. It figures out renaming on import. Plus it babysits the kids
and does light housekeeping! http://freshmeat.net/projects/mcvs



___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Again: multiple vendors

[Kaz Kylheku]

On Sun, 6 Mar 2005, Baurzhan Ismagulov wrote:

> Thanks to all for comments and suggestions!

The CVS vendor branch feature has a broken design. At best, it can be
used to track new versions of the original baseline that was used to
create the repository with ``cvs import''. Even for that, it is
troublesome.

The first problem is that ``cvs import'' operates directly on the
repository. It does not create a sandbox which you can inspect for
differences against the repository and possibly throw-away, if
necessary, or commit if you are satisfied. In other words, go through
the regular pre-commit review. Secondly, you can end up with a
half-baked main trunk, in which files that are not locally modified are
replaced by new head revisions from the vendor branch, but files which
are locally modified are not replaced even if new changes exist for
them in the vendor branch. I.e. the most ``obviously safe'' vendor
changes are applied to the main trunk, and the rest you must do by a
manual merge, until which is done, you have inconsistency.

The second problem, the huge one, is that vendor branches all shoot
from revision 1.1 of every file, because they all share the 1.1 digits.
Branch 1.1.1, 1.1.3, 1.1.5, ... all are based on 1.1. This assumption
means that all the teams have exactly the same starting baseline that
they are patching, forever. What's ironic is that vendor branching
plays weird games with the RCS structure, on top of what normal
branches do, in spite of providing fewer features. There is that
question of the strange version 1.1.1.1 that is exactly the same as
version 1.1. You don't see this in a normal branch. If you create a
regular branch off version 1.3, you don't get some 1.3.1.1 version of
the file. You get /no/ new version of the file until you commit
something to the branch, and /then/ you get a version node like
1.3.2.1. (Or 1.3.4.1 if the branch number is 1.3.4, etc).

In the Meta-CVS version control tool, I implemented a tool for
third-party-source tracking that uses regular CVS branches underneath.
(Meta-CVS does not even have an ``import'' command, to avoid confusion.
The underlying ``cvs import'' is only used when one creates a
repository for the first time from some sources, and that command is
``mcvs create'').

In Meta-CVS, to track sources from a third party, first you identify
what baseline they are using. In the ideal case, it corresponds exactly
to some tagged baseline in your repo. So what you do first is create a
branch from that tagged baseline. 

Now that you have a branch from the baseline that the third party
patches are made from, you use ``mcvs grab -r '' to bring
the outside code to the tip of the branch.

What ``mcvs grab'' will do is convert the current directory and its
children into a Meta-CVS sandbox, by adding all the missing pieces that
a sandbox has. Moreover, it will analyze the files, and figure out file
moves and symbolic link reconfigurations.  Thus the sandbox will
basically express a minimized set of edits, including directory
structure edits, which one has to commit to sync the branch
to the new baseline. You can view diffs, make additional touchups, if
needed, and then commit the changes.  If you aren't happy, just delete
the MCVS/ subdirectory and the tree is no longer a sandbox. In fact, it
hasn't been touched at all. Until you commit, nothing happens in the
repository. And after that, nothing happens to your main trunk or any
other branch. Oh, and speaking of the main trunk, you can ``mcvs grab''
onto the trunk too. This takes care of a CVS FAQ: ``help, we branched
wildly, haven't used the main trunk in like a year, and now we just
want to replace the tip of it without merging''. No problem.

To merge the branch, you do it like any other branch. Of course, since
you are using ``managed branches'' in Meta-CVS which track what has
been merged, it's a simple command: ``mcvs merge '',
review everything and commit.  If you screw up the merge, just throw
away the changes, and then ``mcvs remerge '' will re-apply
the last merge.

When you merge from a branch, you can do some useful things, like
manually throw away some renames in order to assert ``we don't want
these directory structure changes being done on this branch, just the
content bugfixes''. The vendor can then continue providing patches
using /their/ modified directory structure, and they get nicely merged
down into /your/ directory structure. 

-- 
Meta-CVS: the working replacement for CVS that has been stable since
2002.  It versions the directory structure, symbolic links and execute
permissions. It figures out renaming on import. Plus it babysits the kids
and does light housekeeping! http://freshmeat.net/projects/mcvs



___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cross-directory merge

[Kaz Kylheku]

On Wed, 9 Feb 2005, Adam Jenkins wrote:

> 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.

This problem is tackled in Meta-CVS, by design.

-- 
Meta-CVS: the working replacement for CVS that has been stable since
2002.  It versions the directory structure, symbolic links and execute
permissions. It figures out renaming on import. Plus it babysits the kids
and does light housekeeping! http://freshmeat.net/projects/mcvs



___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs vs. clearcase?

[Kaz Kylheku]

On Tue, 21 Dec 2004, Andrew DeFaria wrote:

> How many times do you alter the source code to provide site specific 
> functionality? And what do you do when the next version of CVS comes out?

You merge!

On a previous job, I maintained site-specific extensions to WinCVS, and
merged them against new public releases.

(In one case, the merge was quite difficult, because the framework for
handling columns in the file browsing view was rewritten, so the
columns I added had to be retargetted to that framework).

Most of the merges were easy though.

Of course, I used CVS for the merging.

These days, I'd use my Meta-CVS, which has better support for tracking
third-party sources. A normal branch can be used as a vendor branch,
and the import tool ``mcvs grab'' figures out renames (and looks at
symbolic link reconfigurations and execute permission changes too).
So merging is possible even if you have locally renamed or moved some 
files, and the new snapshot does the same.

-- 
Meta-CVS: the working replacement for CVS that has been stable for two
years.  It versions the directory structure, symbolic links and execute
permissions. It figures out renaming on import. Plus it babysits the kids
and does light housekeeping! http://freshmeat.net/projects/mcvs






___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Getting user id when committing?

[Kaz Kylheku]

On Tue, 3 Aug 2004 [EMAIL PROTECTED] wrote:

> I need to write a script that maps a cvs/unix user id
> to a bugzilla user id. I know CVS knows the user that
> "cvs commits" a change. How do I get this info? Is it
> the %s variable?

If you use proper Unix accounts for your CVS users, then your
commitinfo script can simply look at the effective user ID of its
process, for instance using the ``id'' command.

-- 
Meta-CVS: the working replacement for CVS that has been stable for two
years.  It versions the directory structure, symbolic links and execute
permissions. It figures out renaming on import. Plus it babysits the kids
and does light housekeeping! http://freshmeat.net/projects/mcvs



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: coaxing scientists to use cvs

[Kaz Kylheku]

On Thu, 8 Jul 2004, Hensley, Jeffrey L ERDC-ITL-MS Contractor wrote:

> I've been working together with a group of about 6 engineers/scientists for
> over a year. These are all bright people, but software engineering is not
> one of their strong suits. I managed to convince them to start using CVS to
> try to help maintain the scientific package that they are developing.

I say, just leave them alone to do whatever they want. Their success is
in their own hands. Just don't tie your own success to theirs, that's all.

-- 
Meta-CVS: the working replacement for CVS that has been stable for two
years.  It versions the directory structure, symbolic links and execute
permissions. It figures out renaming on import. Plus it babysits the kids
and does light housekeeping! http://freshmeat.net/projects/mcvs



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Merge Branch to Trunk - Not Deleting Lines in Trunk

[Kaz Kylheku]

On Thu, 24 Jun 2004, work wrote:

> Date: Thu, 24 Jun 2004 09:59:16 -0400
> From: work <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Merge Branch to Trunk - Not Deleting Lines in Trunk
> 
> When I merge from the file on the branch to the file on the trunk, and the 
> file on the branch has deleted lines, the lines are not deleted from the 
> file on the trunk. 
> 
> I'm in the local sandbox for the trunk and using the cvs update -j 
> latest_branch_tag -j latest_trunk_tag and the output says that the file 

This is wrong. Both -j tags should be in the stream that is the source
of the merge, not in the current stream being merged into.


# merge differences made after merge 10, up to the
# point where the merge 11 tag was applied:

cvs up -j merge_010_branch_tag -j merge_011_branch_tag

> already contains the differences, but it really doesn't because the lines 
> don't exist in the branch, but do in the trunk.

The output is correct. You have specified the merge delta 
latest_branch -> latest_trunk.  The branch doesn't have the lines, but
the trunk does. So it looks like you are merging a patch which *adds* the
lines.  Since you are on the latest trunk, that copy already has the
lines, hence ``contains the differences ...''.

RTFM.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Why should you want to remove sticky tags?

[Kaz Kylheku]

On Fri, 18 Jun 2004, Anand Graves wrote:

> Date: Fri, 18 Jun 2004 21:48:55 +0200 (CEST)
> From: Anand Graves <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Why should you want to remove sticky tags?
> 
> 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?

That is not a sticky tag.

> Or perhaps I am confused about Tags and Sticky Tags.

A sticky tag is persistant state information stored in the local
sandbox which retains and automatically applies a revision argument
to a commit or update command. The sticky version can be numeric or
symbolic, or it can be a date.  The sticky state is recorded when an
update or checkout specifies a revision. It is cleared when you switch
to the trunk (update -A).

When there is no sticky tag, updates come from the main trunk (the
default branch), and commits go there. 

When there is a sticky branch tag, updates come from the branch and
commits go there.

When there is a sticky non-branch tag, updates do nothing, and commits
are blocked with an error message.

That's pretty much it!

-- 
Meta-CVS: the working replacement for CVS that has been stable for two
years.  It versions the directory structure, symbolic links and execute
permissions. It figures out renaming on import. Plus it babysits the kids
and does light housekeeping! http://freshmeat.net/projects/mcvs



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs merging - conflict

[Kaz Kylheku]

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:

  is different from 

 is different from 

There is no telling how such differences will affect some process that
uses that XML as input.

If there are merge conflicts due to different line terminators, that is
a different problem. CVS stores text files in a canonical format on the
server, and converts them to and from the client's text file
representation. So normally there are no problems.

Sometimes people things which cause this scheme to break.  For instance
they transfer files between systems that have a different text file
format without converting them, and then commit them into CVS. So you
end up with stray ^M characters when checking out these files.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs merging - conflict

[Kaz Kylheku]

On Thu, 17 Jun 2004, Feldmann, Rick wrote:

> I read somewhere that cvs update uses diff to figure out modifications to
> the files.  

The merging algorithm is based on the three-way merge program diff3. 

> However, it doesn't appear to use the same diff as cvs diff -

That's correct. diff and diff3 are diff-erent animals. 

> Part of it is the white space issue, and there doesn't appear to be and
> option in update to ignore white space.

That wouldn't make sense. Ignoring any differences would cause update
to become unreliable.

Suppose that developer A commits a bugfix in some programming language
where whitespace is significant. The bugfix changes a file in
whitespace only. Developer B runs cvs update, which decides that the
fix is not important and so doesn't incorporate it into his working
copy. Oops!

The machine can't blindly throw away information in the output when
computing a merged version.  The output of a merge operation is a new
working copy which will eventually make it back to the repository.

Ignoring whitespace differences in the output of diff is okay, because
such diffs are just for human consumption; they don't serve as input
back into the machine. For instance, such diffs can't be trusted to be
useful as patches.

If in a C program I change  #define x ()  to #define x(),  then a patch
produced with diff -ub will miss that change! Consequently, someone
applying the patch won't get the correct bugfix.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Multi-branch development without cvslines or temporary insanity

[Kaz Kylheku]

On Wed, 16 Jun 2004, Doug Lee wrote:

> What I'm hoping is that somebody out there has a strategy for
> simplifying the process of updating one or more branches (possibly
> including the trunk) from a particular branch (which could be the
> trunk, AFTER a series of commits have been made to that branch.

Meta-CVS contains logic for branch management. When you create a
branch, it adds the necessary tags to keep track of the branch point.

You can merge from a branch to any branch; it uses a separate set of
tags to track the merges for each source-target combination.

This is useful, for instance, if a branch contains the development for
some feature that is of interest on some other branches.

The user does not have to be aware of any tags, just execute commands
that reflect high level branching and merging use cases.

-- 
Meta-CVS: the working replacement for CVS that has been stable for two
years.  It versions the directory structure, symbolic links and execute
permissions. It figures out renaming on import. Plus it babysits the kids
and does light housekeeping! http://freshmeat.net/projects/mcvs



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Managing multiple branchs

[Kaz Kylheku]

On 20 Apr 2004, Barry Svee wrote:

> out of synch with trunk. So, after all support issues have been fixed,
> it would be nice to tag trunk and then have the support branch reflect
> that tag as its new starting point.

A branch can't have a new starting point. You have to merge down all
your latest changes from the existing production branch to the trunk,
and then start a new production branch.

You might not want to do that right away either; the typical process
involves some integration, testing and other development work before
identifying a baseline that will be the new production release.

-- 
Meta-CVS: the working replacement for CVS that has been stable for two
years.  It versions the directory structure, symbolic links and execute
permissions. It figures out renaming on import. Plus it babysits the kids
and does light housekeeping! http://freshmeat.net/projects/mcvs



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Pinning in CVS

[Kaz Kylheku]

On Sun, 14 Mar 2004, Conrad T. Pino wrote:

> > -Original Message-
> > From: [EMAIL PROTECTED] On Behalf Of George Abraham
> > Sent: Thursday, March 11, 2004 01:58
> > To: [EMAIL PROTECTED]
> > Subject: Pinning in CVS
> > 
> > Is there any method by which the "Pinning Feature" in VSS can be implemented
> > in CVS ?

> Date: Sun, 14 Mar 2004 13:40:03 -0800
> From: Conrad T. Pino <[EMAIL PROTECTED]>
> To: George Abraham <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: RE: Pinning in CVS
> 
> See the "-D" or "-r" options for CVS "checkout" or "update".
> 
> When "-D" or "-r" are used this information persists in local copy
> i.e. the date or revision tags are "sticky".  Read following:

This is not exactly the pinning feature. The pinning feature of VSS is
an escape hatch that is used when people realize that sharing files
was a bad idea, and that people are now breaking each other's projects
when they check in changes to shared files without verifying the
changes for each one of the N projects.

What you can then do is, in the repository, asssert that you don't want
to get new versions of certain shared files. You want them to be stuck
at a certain revision. This is a policy for everyone checking out your
project (but it doesn't affect someone checking out the same files 
through some other link).

-- 
Meta-CVS: the working replacement for CVS that has been stable for two
years.  It versions the directory structure, symbolic links and execute
permissions. It figures out renaming on import. Plus it babysits the kids
and does light housekeeping! http://freshmeat.net/projects/mcvs



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Can wincvs graph all versions/branches for a module?

[Kaz Kylheku]

On Thu, 11 Mar 2004, McMaster, James C (Jim) wrote:

> Some members are still complaining about all the things cvs "won't do", and
> pining for Visual SourceSafe.

These people need their heads examined.

> So far, I have been able to demonstrate almost everything, except one.
> Apparently, VSS can show a graph of versions/branches for a module, and I
> cannot figure out how to do that in wincvs.  The graph function seems only
> to work for individual files.  Am I missing some way to do this?

No. But on the other hand, VSS requires you to merge files
individually. So being able to see the module's graph as a unit rather
than file-by-file is only a poor consolation prize.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Win<->Linux symbol case conflict

[Kaz Kylheku]

On Fri, 5 Mar 2004, Iakov Glubokiy wrote:

> Date: Fri, 5 Mar 2004 09:26:22 +0300
> From: Iakov Glubokiy <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Win<->Linux symbol case conflict
> 
> Hello all,
> 
> I met a problem tying to replace file AAA.EXT by aaa.ext. My
> client is NT while server is Linux.
> So when I do the following:
> 
> D:\main\cvs rm -f AAA.EXT
> [...]
> D:\main\cvs ci -m"Changing symbol case" AAA.EXT
> [...]
> D:\main\cvs add aaa.ext

Meta-CVS, has proper renaming.

   mcvs mv AAA.EXT aaa.ext
   mcvs ci -m "Case-changing rename"

Meta-CVS can also deal with the case of names that do not conflict on
UNIX, but do conflict on Windows.

Suppose that the project contains "FOO.C" and a UNIX user renames
an existing "blorg.c" to "foo.c" and commits. On his machine, there is
no conflict, because "FOO.C" and "foo.c" are distinct names. 
But you are on Cygwin/NTFS and do a ``mcvs up''.

When reshaping the tree, Meta-CVS will try to create "FOO.C" and
get an error from the filesystem. 

This is turned into a condition about a local file being in the way.
Although this is not quite accurate because it's not really a local
file, if you choose to terminate, the behavior is fail safe.

$ mcvs up
cvs update: Updating .
M MAP

The following error has occured:

some moves or adds want to overwrite local files or directories.

You have these alternatives:

?) Re-print this menu.
I) (Info) Print list of adds or moves which want to overwrite.
C) (Continue) Go ahead and overwrite the target files.
A) Auto-continue all continuable errors.
T) Recover, clean-up and terminate.

>I
move blorg.c -> FOO.C
>T
restoring blorg.c

$

The filesystem reshaping is rolled back, and so now you have an
inconsistent tree; there are outstanding changes in the MAP which are
not reflected in the tree structure. You now have an opportunity to fix
the MAP to eliminate the inconsistencies, either by hand or using the
command interface.

Check this out. You rename your file out of the way, and now that there
are no problems, the tree restructuring completes itself. Two files
are in fact moved, because after your local move request, there are two
outstanding moves, which can now complete without conflict:

$ mcvs mv foo.c out-of-the-way.c
* moving foo.c -> out-of-the-way.c
* moving blorg.c -> FOO.C

The tree reshaping is done and everything is now consistent and cool
as far as version control is concerned. 

We need is a more accurate diagnostic in Meta-CVS, since this is not a
case of a local file being in the way, but a case conflict.  Choosing C)
in the menu would be a pretty bad idea (overwrite the file). That choice
must not be available when it's a case-insensitivity conflict between
two versioned files.

-- 
Meta-CVS: the working replacement for CVS that has been stable for two
years.  It versions the directory structure, symbolic links and execute
permissions. It figures out renaming on import. Plus it babysits the kids
and does light housekeeping! http://freshmeat.net/projects/mcvs



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: multiple merge tricks

[Kaz Kylheku]

On Thu, 26 Feb 2004, Iakov Glubokiy wrote:

> I'd like to discuss some thoughts about merging from a branch several
> times. AFAIU, Cederqvist ommited the tiny fact that using double -j
> one can lose some data. He says:
> 
> 
> Continuing our example, the revision tree now looks like this:
> +-++-++-++-++-+
> ! 1.1 !! 1.2 !! 1.3 !! 1.4 !! 1.5 ! <- The main trunk
> +-++-++-++-++-+
> !   *
> !  *
> !   +-++-+
> Branch R1fix -> +---! 1.2.2.1 !! 1.2.2.2 !
> +-++-+
> where the starred line represents the merge from the ‘R1fix’ branch to
> the main trunk, as just discussed.
> Now suppose that development continues on the ‘R1fix’ branch:
> +-++-++-++-++-+
> ! 1.1 !! 1.2 !! 1.3 !! 1.4 !! 1.5 ! <- The main trunk
> +-++-++-++-++-+
> !   *
> !  *
> !   +-++-++-+
> Branch R1fix -> +---! 1.2.2.1 !! 1.2.2.2 !! 1.2.2.3 !
> +-++-++-+
> 
> 
> well, in that certain case suggested
> 
> cvs update -j 1.2.2.2 -j R1fix m.c
> 
> works fine.
> But in more common case, when the trunk was changed too, we can
> overwrite changes in trunk by changes in the branch! Where single -j
> update produces conflict, double -j produces overwrite. Look:

That is not by design. If you actually have a test case that reproduces
an instance of overwrite, you should discuss that.

> 
> +-++-++-++-++-+
> ! 1.1 !! 1.2 !--...---! 1.5 !! 1.6 !! 1.7 ! <- The main trunk
> +-++-++-++-++-+
> !   *
> ! *
> !   +-++-++-+
> Branch R1fix -> +---! 1.2.2.1 !! 1.2.2.2 !! 1.2.2.3 !
> +-++-++-+
> 
> Here
> 
> cvs update -j 1.2.2.2 -j R1fix m.c
> 
> conflicting changes at 1.2.2.3 just discard changes at 1.6-1.7

Conflicting changes should produce conflict markers.

You should see a 3-way merge performed with 1.2.2.2 as the ancestor,
and 1.7 (your working copy) and 1.2.2.3 as the two descendants.

Your approach can produce bad merges in a different way. If you use the
tip of the branch as the second argument to -j, you have potential race
conditions between the merge and other people doing commits on the
branch:

  cvs update -j branch_x_last_merge -j branch_x

  #  resolve conflicts, commit
  #  ... meanwhile more changes are added to branch ...

  cvs tag -F -r branch_x branch_x_last_merge

  # last merge tag is moved to the tip, skipping over new changes!

Always place a stable tag at the tip of the branch, and then merge to
that. Use that tag as the starting point for the next merge.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Tagging

[Kaz Kylheku]

On Sat, 21 Feb 2004, Larry Jones wrote:

> Date: Sat, 21 Feb 2004 14:40:50 -0500 (EST)
> From: Larry Jones <[EMAIL PROTECTED]>
> To: Kaz Kylheku <[EMAIL PROTECTED]>
> Cc: CVS <[EMAIL PROTECTED]>
> Subject: Re: Tagging
> 
> Kaz Kylheku writes:
> > 
> > You have to pick a representative file, and view the ``cvs log'' for
> 
> If you're only interested in tags, you might find ``cvs status -v'' more
> friendly (you get less extraneous information).

Right, that or ``cvs log -h''.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Tagging

[Kaz Kylheku]

On Fri, 20 Feb 2004, Merina Francis wrote:

> Now suppose user X want see the different tags for my module. How user x
> can know that how many tags(Revisions) I have made for my module.I hope
> the problem is clear.Is there any cvs command for that if yes, how can I
> do that ?

You have to pick a representative file, and view the ``cvs log'' for
that file. Ideally, the representative file is one that has always
existed in the module since the beginning, and has not been removed
from any branch. Therefore it carries every tag that was ever made over
the entire module. By parsing the output of ``cvs log'' over that file,
you can obtain that list.

In the Meta-CVS version control system, we have such a representative
file in CVS, namely the file called ``MAP''; it is present from the
time the module is created, and is never deleted from any branch.
Having such well-known file makes it possible to do some neat things in
a reliable way.

-- 
Meta-CVS: the working replacement for CVS that has been stable for two
years.  It versions the directory structure, symbolic links and execute
permissions. It figures out renaming on import. Plus it babysits the kids
and does light housekeeping! http://freshmeat.net/projects/mcvs



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: how to support symlinks?

[Kaz Kylheku]

On Wed, 18 Feb 2004, Robert P. J. Day wrote:

> > Probably means FTP, ie
> > .  But the
> > file is not at that location.  Sorry, I don't know where the current
> > version is.
> 
> my problem exactly.  :-)  given that this is a problem that hundreds
> before me have tripped over, i'm assuming there's a standard solution.
> i'm just trying to find it.

Meta-CVS supports symlinks. You can ``mcvs add'' a symlink under version
control, or use ``mcvs ln'' to create one.  You can move or rename them
with ``mcvs mv'' just like files, and likewise remove them with 
``mcvs rm''.  Symlinks appear, disappear, move or retarget as needed
when you fetch versions with ``mcvs up''.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Commit to trunk from branch

[Kaz Kylheku]

On Wed, 18 Feb 2004, Lemke, Michael  IZ/HZA-IOP wrote:

> Date: Wed, 18 Feb 2004 17:57:26 +0100
> From: "Lemke, Michael  IZ/HZA-IOP" <[EMAIL PROTECTED]>
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Subject: Commit to trunk from branch
> 
> Suppose I am on a branch.  I add a file.  How do I commit it to the trunk?
> Instead of the branch.

In CVS, you don't commit branches. Committing means publishing local
changes to the repository.

To propagate changes from a branch to the trunk, you check out a working
copy of the trunk, and then apply the branch changes to the working
copy. The changes then become local edits, exactly as if someone had
done them by hand. These changes can then be committed to the trunk.

Applying the branch changes to the working copy is called merging. It's
a mostly automatic process, but it can produce conflicts that have to
be resolved. You have to hunt down the conflict markers in the files
and perform an edit to correct the situation. Even when there are no
flagged conflicts, the result of a merge has to be carefully verified.

Merging in CVS is done by using ``cvs up'' with one or two -j options.
With one -j option, you typically specify the branch. CVS figures out
the common ancestral version between your working copy and the branch
and does a three way merge. With two -j options, you specify arbitrary
versions. The left version is treated as the ancestor, and the right
version as the descendant. A three way merge is done using that ancestor,
descendant and your working copy.

CVS doesn't track what has been merged from where; it gives you this
patching operation and the rest is up to you. Tracking merges is done
using various conventions involving tags. Read the CVS manual. :)



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Versioning large files

[Kaz Kylheku]

On Mon, 16 Feb 2004, Paul Gelderblom (ptok) wrote:

> It would be nice if CVS had an additional (parallell) system for versioning
> binary files in a less resource-intensive manner, but it probably will never
> come to that. (I would say, make a hack of the rcs file format which just
> contains versioning information and tags etc, and links to basically copies
> of the binary file versions in the same directory. Add a checksum to
> maintain integrity. It may not be subtle, but it will certainly work. And
> disk space is cheap.)

Hey, I wonder whether this is something I can hack in Meta-CVS. All I
need is a MAP entry with a path to the object and checksum:

  (:EXTERNAL-FILE "/sandbox/path/to/it" "UNIQUE-ID" 
   "URI://where/is/it" 13948394894)

There would have to be some clever way of locating these external
files, such as a local configuration file mapping abstract locations to
concrete locations. You don't want hard-coded locations in version
control because then people can't move the database.

You want to be able to do things like give people CD-ROM images with
all these large binaries and then have them configure their sandbox so
it can refer to these local replicas.

When the user does a ``mcvs up -r old-release'', it will find the old
version of the binary on the newly installed local replica, rather than
pull up some obsolete path name to a location that no longer works.

-- 
Meta-CVS: the working replacement for CVS that has been stable for two
years.  It versions the directory structure, symbolic links and execute
permissions. It figures out renaming on import. Plus it babysits the kids
and does light housekeeping! http://freshmeat.net/projects/mcvs



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Multiple sources in a vendor branch

[Kaz Kylheku]

Rohan Nandode <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> Hi,
> 
> The problem descriptions goes like this:
> 
> I have a vendor branch(1.1.3) for 3rd party library - say "library1" 
> along with my project source in my CVS. I have done some modifications 
> to the sources in library1.
> Now I there is a latest release of the library1 and I would like to 
> upgrade it. But the problem is that I am not sure of how much stable 
> will be the upgraded version. 

Vendor branching is a braindamaged feature of CVS. There are a number
of problems with it.

- Each vendor branch shoots from version 1.1 of every file. If you
suddenly develop a relationship with a vendor who wants to make
patches based on some some other baseline---for instance, a release
that you made---you can't use the vendor branch.

- When you import to a branch, some files that are unmodified in your
main trunk are superseded by way of setting the RCS head revision to
the branch. So a check out of the branch produces a mixture of true
main trunk files and vendor branch files, a kind of half-baked merge.
This game playing with the head revision is an optimization, like the
Attic directories.

In Meta-CVS, I have implemented sane vendor branching. A command
called ``grab'' checks out the material, compares it against the
snapshot you are importing and then produces a sandbox which you can
commit to complete the import. Nothing happens in the repository until
you are happy with the diffs and do a commit. Files and symbolic links
are analyzed to automatically detect renames and moves. If you aren't
happy with the results, just scrap the MCVS/ directory and try again.
You can grab to any branch or main trunk. Branching and merging is
easy in Meta-CVS, because it does all the underlying CVS tagology
(taggery? tagistry?)

   cd vendor-foo-drop
   mcvs grab -r vendor-bar-branch my-project

   # oops made a mistake, selected wrong branch

   rm -rf MCVS  # no problem

   mcvs grab -r vendor-foo-branch my-project
   mcvs commit

   mcvs sw# no args, switch to main trunk
   mcvs merge vendor-foo-branch
   mcvs commit
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: What's to stop a developer from ...

[Kaz Kylheku]

hacking the CVS server with an axe, then setting fire to the whole
building?

You see, I'm evaluating the advantages and disadvantages of various
version control systems, so I'd like to know how secure CVS is.

:)



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: distributed CVS repositories

[Kaz Kylheku]

On Wed, 14 Jan 2004, Sarah Gonzales wrote:

> Date: Wed, 14 Jan 2004 10:24:36 -0600
> From: Sarah Gonzales <[EMAIL PROTECTED]>
> To: Purushotham Komaravolu <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: distributed CVS repositories
> 
> Take a look at CVSUp - there may be others as well.

There is DCVS, a project based on cvsup that goes a few steps beyond;
it uses a modified cvs client and server to manage local lines of
development. It ensures that when you create a branch, it uses a branch
number from a range assigned to your server, so that the deltas on your
branch can be synced to another node without conflicts.

The cvs command is replaced by dcvs, CVS/ directories by DCVS/
CVS* environment variables by DCVS* and so on.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: How to echo log message if commitinfo rejects commit

[Kaz Kylheku]

On Thu, 8 Jan 2004, Bil Kleb wrote:

> We just started using commitinfo to enforce rudimentary coding standards.
> So far, we appreciate the gentle reminders from the script it invokes.
> 
> But we have discovered one minor annoyance: When the proposed commit is
> rejected, the log message is lost -- unless the committer remembered to
> save a copy of their log entry beforehand.

You can use -m to specify a commit message on the command line, or -F
to have it come from a file. I think that smart users will soon learn
to do this after losing a few commit messages. ;)

Another solution is to use a GUI that persists the commit message
between invocations of the commit dialog box.

Similarlly, you can easily write a simple script wrapper around ``cvs
ci'' which brings up the editor over a fixed path, to create the effect
of a persistent commit message. That path can be handed to ``cvs ci''
via the -F parameter.

> After an hour of googling and reading the CVS manual, I am still not sure
> how I can gain access to the log message so that I can echo it's contents
> to standard output, allowing the user an opportunity to cut and paste the
> log message into their next commit attempt -- if they did not remember to
> save the original.

This seems like a klunky design anyway; the log message has to travel
to the server and back. What if it never makes the round trip because
of some network problem or a deliberate interruption of CVS?

A good solution would be one that persists the message even if the user
interrupts CVS with Ctrl-C.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Is a multiple pserver possible?

[Kaz Kylheku]

On Tue, 6 Jan 2004, Greg A. Woods wrote:

> Date: Tue, 6 Jan 2004 21:28:11 -0500 (EST)
> From: Greg A. Woods <[EMAIL PROTECTED]>
> Reply-To: CVS-II Discussion Mailing List <[EMAIL PROTECTED]>
> To: Anne Henmi <[EMAIL PROTECTED]>
> Cc: CVS-II Discussion Mailing List <[EMAIL PROTECTED]>
> Subject: Re: Is a multiple pserver possible?
> 
> [ On Tuesday, January 6, 2004 at 15:08:55 (-0800), Anne Henmi wrote: ]
> > Subject: Re: Is a multiple pserver possible?
> >
> > Here's the kicker.. he wants to have an "anonymous" user for each
> > project (with the username "proj1", "proj2", etc) for accessing each
> > separate repository.
> 
> Well it is possible to provide anonymous SSH access, even in such a way
> that "cvs server" is the only command the remote user is allowed to
> execute, though the exact details on how to configure this are specific
> to the SSH server implementation you use (and I don't have them handy at
> my fingertips for either well known implementation :-).

One powerful way to do it is to make the user's login shell a command
validating and filtering shell script. I posted something like that to
Usenet in August 2000. Message-ID: [EMAIL PROTECTED]

This script indeed only allows ``cvs server'', but it goes one step
beyond that and adds a ``-d '' parameter before ``server''.
This way the remote user cannot freely specify the repository by
smuggling over a CVSROOT environment variable. You can tie specific
users to specific repositories with a bit more coding. If the user is
``proj1'', you have ``-d /path/to/proj1-cvs'' and so on.

I used this script, or a very similar one, in a real situation. I
wanted to allow only CVS access, file copying (via scp) to and from the
user's home directory only (so the remote users could exchange files
with our team) and listing of the home directory.

-- 
Meta-CVS: directory structure versioning; versioned symbolic links;
versioned execute permission; versioned property lists; easy branching
and merging and third party code tracking; all implemented over the
standard CVS command line client -- http://freshmeat.net/projects/mcvs



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs commit/up's change file ownership in working dir.

[Kaz Kylheku]

On Mon, 5 Jan 2004, Patton, Matthew E., CTR, OSD-PA&E wrote:

> I have a file owned root.named. root wasn't a member of said group but I
> tested with root being a member (not primary group) and it still does the
> same thing (if 'named' were the primary group for 'root' I'd be ok in this
> one very narrow instance). When I commit a file, cvs is changing the file
> ownership to the default for that account: namely root.root which destroys
> my setup.

Read up on the setgid bit on directories. When you create a file or
subdirectory, it does not automatically inherit the group ownership of
the directory into which it is linked. 

You can get that behavior, the parent directory has to have the setgid
bit set in its permission mask.

For executable files, setgid means ``run the process under this
effective group ID''. For directories it means ``create new elements
with this group ownership''.

> I think we need to move beyond simply creating in the working
> directory a file owned by whatever fopen(2) comes up with.

No we don't. The POSIX operating system interface is designed such that
programs can use the fopen() function without worrying about it. It does
the right thing based on the process security context, umask, and
permissions of the directory.

> Does anyone actively use the PRESERVE_PERMISSIONS_SUPPORT capability? Is it
> being maintained? My quick look thru the source says it stuffs "owner,

Versioning permissions is a bogus idea. When you check out files, they
should be created such that they are accessible to you.

Client-server CVS does not require the sharing of any authentication
databases; you can check out from a remote server without having access
to its password database. If the files in the CVS server are
group-owned by ``cvsusers'', there is no need for such a group to exist
locally. Your client machine doesn't even have to run a UNIX-like client system.

> For example if "joe" and "todd" are editing files, whoever commits last
> could end up setting "file owner|group; " to their uid/gid because that's
> how the file is in their working set.

It all works properly because it's based on the UNIX model. 

Imagine that instead of using the CVS client and server, joe and todd
were logged into the CVS machine and were hand-editing the files in
the repository.

The operating system already has features to handle this type of
sharing. It's a multi-user system! CVS just builds on it by acting as
a remote shell, if you will.

Where would we be if you couldn't log in a bunch of users into a UNIX
box, put them into a group, and have them share some files in a
directory? Hello?

>If 'jane' does a 'cvs up' her files
> will have to be owned by her because I'm pretty sure she won't be 'root' and
> thus able to chown/chgrp arbitrary file owners ('joe' or 'todd') to her
> files.
> 
> Permissions are more challenging. Sloopy 'joe' can't be bothered with
> security so he just mode 666's every file he deals with.

Firstly, Sloppy Joe can't change the mode of files that he does not own.
Secondly, there can be a nice

  umask 007

in the global login script which will cause Sloppy Joe's, and everyone
else's files to be created 0660. Of course, users can override that or
use chmod. That is their choice.

You can't implement security if you have users who don't care about it.
No matter what you implement in the computer system, uncooperative
users can leak information and find ways to delegate their access to
unauthorized users.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Original CVS Shell Scripts

[Kaz Kylheku]

On Wed, 10 Dec 2003, SCMLinux for CM wrote:

> I'm looking for the original CVS shell scripts that were written
> to interact with RCS.  Is there a quick link I can go to that has the
> archived scripts?

They were posted to the mod.sources Usenet newsgroup by Dik Grune
sometime in 1986 as a shell archive. You can pull two-part posting out
of Google Groups.

The message ID's for the two parts of the shar are:

 [EMAIL PROTECTED]
 [EMAIL PROTECTED]

They didn't need very unique message ID's in those days. ;)



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Preventing users from Tagging files

[Kaz Kylheku]

On Tue, 25 Nov 2003, Mike wrote:

> I am aware that I can use the unix file system permissions to prevent
> developers from checking in files into CVS. But is there a way to prevent

In addition, you can use the commitinfo scripting mechanism to stop commits
for just about any criteria: bad code formatting, missing bug number
in the log message, etc.

> people from TAGGING files [or retagging] while still letting them checkin
> those same files? Or am I just asking a stupid question?

You can implement your custom restrictions in a script specified in 
the taginfo administrative file.  The taginfo script could check the
user identity and reject the operation if that identity is blacklisted.

(But really, if you can't trust some developers to tag properly, how
can you trust them to commit anything?  Learning a tagging system and
sticking to it is far less complex than all the things you have to do
to become a competent software developer. :)



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: checkout -D & -P

[Kaz Kylheku]

On Wed, 19 Nov 2003, gilmurra wrote:

> I don't understand why the -D  option to checkout also implies -P.
> Can anyone explain this to me? This is not idle curiosity; I have a
> situation where I need -D  and an empty directory. Is there a way
> to override the implied -P?

If you need a directory to exist regardless of -P, then you have to use
some trick, like storing an empty file in it which has a visible
version as of the -D date or -r tag that you are checking out.

If you make that file now, its newly created 1.1 version will be out of
range for an old -D date, so the trick won't work.  You can hand-edit
the RCS file to give that version an old date, and also any branch
or version tags needed to ``fake out'' its history, so that the empty
directory gets created when these symbolic revisions are used.

-- 
Meta-CVS: directory structure versioning; versioned symbolic links;
versioned execute permission; versioned property lists; easy branching
and merging and third party code tracking; all implemented over the
standard CVS command line client -- http://freshmeat.net/projects/mcvs



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: why don't relative paths work when specifying a remote repository ?

[Kaz Kylheku]

On Mon, 10 Nov 2003, Larry Jones wrote:

> Date: Mon, 10 Nov 2003 16:42:52 -0500 (EST)
> From: Larry Jones <[EMAIL PROTECTED]>
> To: "Patton, Matthew E., CTR, OSD-PA&E" <[EMAIL PROTECTED]>
> Cc: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Subject: Re: why don't relative paths work when specifying a remote
> repository ?
> 
> Patton, Matthew E., CTR, OSD-PA&E writes:
> > 
> > Why is "cvs -d [EMAIL PROTECTED]:./some_relative_path" style syntax not supported?
> 
> 1.  Many parts of the CVS code require the root to be an absolute path
> -- allowing a relative path would require either changing all that code
> or adding code to the server to convert the relative path into an
> absolute path.

If you want to abstract the location, you can use symbolic links:

  /secret-cvs-location/myproject

This is semantically as good as

 ./myproject

The /secret-cvs-location component is a symbolic link from the root
directory to wherever you want. If you need to move the repository,
you adjust the symbolic link.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Countering the usual diatribe against binary files, was cvs diff, proposal for change

[Kaz Kylheku]

On Tue, 9 Sep 2003, Tom Copeland wrote:

> On Tue, 2003-09-09 at 12:12, Kaz Kylheku wrote:
> > On Tue, 9 Sep 2003, Tom Copeland wrote:
> > > On Mon, 2003-09-08 at 16:00, Greg A. Woods wrote:
> > > > I can import gigabytes and terabytes of binaries into CVS too, but no
> > > > matter how much I try I'll never be able to use branches meaningfully in
> > > > such a repository, 
> > > 
> > > Hm.  Do CVS branches not work right with binary files?  I've used
> > > repositories that had lots of binary files (mostly jar files) checked
> > > into them with lots of branches and haven't seen problems yet...
> > 
> > JAR files are derived objects, not primary objects.
> 
> Right... although in the case of 3rd party libraries, the line gets a
> bit blurry.  If my project depends on, say, BCEL, I think it's
> reasonable for me to check the BCEL jar file into my module/lib
> directory.

Not necesarily. Your project also depends on some operating systems and
libraries. You don't check in glibc2, the Linux kernel, or every
Windows DLL that your program uses. Your makefile needs GNU make 3.79
or later, so better check that in too!

Sometimes it's okay for binary components and tools to come from
outside of the version control system, subject to some constraints like
``requires glibc 2.1.3 or later, and Linux kernel 2.4.43 or later''.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Countering the usual diatribe against binary files, was cvs diff, proposal for change

[Kaz Kylheku]

On Tue, 9 Sep 2003, Tom Copeland wrote:
> On Mon, 2003-09-08 at 16:00, Greg A. Woods wrote:
> > I can import gigabytes and terabytes of binaries into CVS too, but no
> > matter how much I try I'll never be able to use branches meaningfully in
> > such a repository, 
> 
> Hm.  Do CVS branches not work right with binary files?  I've used
> repositories that had lots of binary files (mostly jar files) checked
> into them with lots of branches and haven't seen problems yet...

JAR files are derived objects, not primary objects. You never have to
care that derived objects are not mergeable, because you merge their
corresponding primary objects (.java source files, in this case) and
rebuild the derived objects.  These newly generated derived objects
are then checked in.

It's usually a bad idea to add derived objects, such as compiled object
files, to the version control system. From time to time it's
justifiable; for example, if you have some large body of stable code
that changes infrequently, it can save you time not to recompile it, at
the cost of a larger repository and longer checkout time.

-- 
Meta-CVS: directory structure versioning; versioned symbolic links;
versioned execute permission; versioned property lists; easy branching
and merging and third party code tracking; all implemented over the
standard CVS command line client -- http://freshmeat.net/projects/mcvs



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Different behavior on VPN

[Kaz Kylheku]

On Tue, 26 Aug 2003, Shankar Unni wrote:

> > Very perplexing to say the least! Does anyone have experience 
> > in accessing CVS over a VPN? We have a developer who called 
> > in from home saying he could not see all versions of a file 
> > in WinCVS. A colleague in the office looked in the same 
> > source tree and could see multiple branches where the guy at 
> > home could only see a single path from the trunk revision!
> 
> What access method is he using? Pserver? Ntserver? Ssh (preferable)? Remote
> disk mounts (God forbid!)?

It sounds as if the -b or -r  parameters are being passed to
cvs log to log the default branch, or the specified branch only.

As a first diagnosis step, I'd have the guy cut and paste me, or read
me the generated cvs command line from WinCVS's output window.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Newbie: problems adding directory to repository

[Kaz Kylheku]

Jesse Sheidlower <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> There was a point at which I was making a lot of changes to my
> dev sandbox, but didn't have access to the repository so
> couldn't commit anything. When I got back to it, I found that
> I couldn't get some things to match up.
> 
> The basic problem is that I had taken a specific program, and
> directory, called Book.pm and Book/ and then generalized it
> and renamed them to MyDatabase.pm and MyDatabase/ . In my dev

CVS doesn't support renaming and moving. You want to be a Meta-CVS
user!

(Meta-CVS even has some support for detecting moves and renames that
were done behind its back, so to speak, rather than using the ``mcvs
mv'' command. The ``mcvs remap'' command will scan the directory tree,
and based on the software's knowledge of the inode numbers of your
files, it will uncover the moves. There are some limitations; if you
move by copying, the inode identity is lost, and remap doesn't find
moved symlinks. It's better to use the proper commands to rearrange
the directory structure!)

In Meta-CVS, directory structure rearrangements are just, effectively,
like any other local edit. They can be done locally without being
connected to the repository, and then committed when you regain
access---and subject to merging and conflict resolution.

In plain CVS, renaming is simulated by deleting files and adding them
under new names. This must be done using the CVS commands ``rm'' and
``add''; CVS will not guess your intent from any direct filesystem
rearrangements you have done.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: How to merge head into a branch?

[Kaz Kylheku]

Roland Roberts <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> -BEGIN PGP SIGNED MESSAGE-
> 
> A couple of weeks ago, I created a branch on a directory in order to
> make some changes to get our project to build with automake/autoconf.
> Meanwhile, other members of the team continue to do work on the head.
> I would like to merge those changes into my branch (at least I think I
> would like to, maybe someone will tell me why that is a bad idea) so

What you really want is to integrate with their latest work, which is
a perfectly reasonable thing to want to do. CVS doesn't support
``merge in any direction'' very well. Perhaps the most effective way
to synchronize with the trunk is to create a new branch from the
trunk. Switch to that newly created branch, and merge your changes to
the working copy from your original branch. When you commit the
results of this merge, it won't got to the trunk but it will instead
be shunted to the new branch! Voila: the trunk developers are not
disturbed, and your work is all synchronized. Moreover, you have not
merged anything in the ``wrong'' direction.

You can keep doing this as long as you want. When your work becomes
stable, you can merge it right to the trunk tip rather than shunting
it to a new branch.

The only drawback is that you don't have your branch all in one piece.
But if you want that kind of undisturbed changeset, then do the entire
work from start to finish without integrating.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: .jpg and .gif

[Kaz Kylheku]

On Thu, 24 Jul 2003, Kristopher Hollingsworth wrote:

> Hey guys, I uploaded my website the other day to our CVS Repository,
> and when we checked it back out some of the image files were corrupt. Any
> idea why this might have happened?

You probably did not give them the ``-kb'' keyword/line-ending
treatment mode to mark them as binary files that must not undergo
CVS keyword expansion or line ending conversion.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Update without merge.

[Kaz Kylheku]

On Mon, 21 Jul 2003, MIke Solem wrote:

> Hello,
> 
> I would like to be able to update my project without CVS merging
> anything.  It should replace unedited files with newer ones if they
> exist.  But files which have been edited (by me but not checked in)
> should be left alone.

This is dangerous: what you are asking for is to navigate from one
version to another, but ignore the delta which takes you there, and not
try to integrate your local changes with that delta.

The result is that your local changes are based against one version,
but will be committed to another, causing the delta to be lost.

For understandable reasons, cvs up does not do this. If you want to
achieve that, you can make backup copies of your modified files,
navigate to whatever version or branch you want, and then copy your
modified files back.

>  I often need to hack up a bunch of files in
> order to run some test.  It would be nice to not have to make all these
> changes again every time I do an update.  Is this possible?  Thanks.

Ah, so what you really want is the default merging behavior. You make
some local hacks to the files. Then when new versions of these files
are made, just do a cvs up. CVS will retrieve newer versions of these
files, and merge the new edits against your local ones. In the best
case, the merge will be made with no conflicts and your local changes will
remain correct---no work no your part! In the intermediate case, there
is some conflict that needs to be resolved, but it's trivial. Some work
on your part, but not as much as re-working those changes. In the worst
case, the new changes make such a conflict that your local work has to
be thrown away and re-done. This is like having no merge at all.
So overall, you win.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Branching & Tags.

[Kaz Kylheku]

On Mon, 14 Jul 2003, Doyle Fouquet wrote:

> If so, then the only thing the developers have to know is where to
> checkout from, the trunk or a branch.  I would further assume that this
> is information that would be given to them by the project manager upon
> assignment of a task. Is my logic correct and the way it should work.

This is generally right; developers should know what to update their
sandboxes to, so that they are working in the right stream and sending
commits there. Someone in the role of a release manager can worry about
tagging baselines, creating branches and so on.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: branches off of branches

[Kaz Kylheku]

On Thu, 19 Jun 2003, Peschko, Edward wrote:

> but it then behooves you to remember when you've done 
> the damn merge..
> 
> Argh! Overall, cvs's branching ability leaves much to be desired. 
> I'd use MetaCVS, except I need to have the functionality available 
> on solaris

What issues have you run into trying to get Meta-CVS on Solaris?

There exists a website ``www.solaris4u.dk'' which hosts categorized
lists of software that apparently run on Solaris. Meta-CVS and other
version control systems are stuck under the ``search engines''
category.

  http://www.solaris4you.dk/searchenginesSS.html

The table suggests that the program was at least built on Solaris 2.8
and 2.9, SPARC and X86.  Maybe the site's maintainer has binaries.

I don't use Solaris, but I'd be happy to incorporate patches, if any,
that are needed to get it running, and host the binary tarballs too.

> (ps - also wrt MetaCVS... why isn't there a sourceforge project for it?)

The conditions are not right.

So far, I have received very few patches for Meta-CVS. Every ChangeLog
entry has my name on it! So there isn't a development team that needs a
central repository.

Read-only repository access for the masses would make sense if it was
such a widely used, busy and buggy program that it was mandatory for
thousands of people to get the latest codebase several times a day
in hopes that the latest and greatest will solve their problems.

A mailing list would be needed for similar reasons. The
Meta-CVS-related traffic that I receive in my personal mailbox is so
small that it doesn't require its own list. The odd time two people
have the same ideas or problems, so I may put them in touch.

A better question is: why isn't there actual working source code for 90%
of the Sourceforge projects? :)



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: branch info

[Kaz Kylheku]

On 18 Jun 2003, Ronald Petty wrote:

> But you can tell this information by just looking at num
> 
> ex.
> 
> 1.2.2.1  (means it branched at 1.2), however if you look at 1.2 it says
> branch 1.2.2.1 is a branch rooted at itself, which is the exact same
> information.

I think that the RCS file format is more flexible than the constraints
that CVS imposes on it for its own purposes. RCS branching is more
flexible with the numbering, from what I can recall.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: branch info

[Kaz Kylheku]

On 18 Jun 2003, Ronald Petty wrote:

> I just reread the rcsfile man page and had the following question.  This
> question might be answered if I read the source code to cvs, but I
> haven't yet.  
> 
> Basically, why do you need have
> 
> branches  {num}*; 
> 
> under the delta node (grammar).
> 
> It seems to be redundant because the 
> 
> num
> 
> that is listed for the given delta has all that information (branch
> points).

No, it doesn't.

> ex.  If the node num is 1.2.2.1
> Why have 1.2.2.1 in the branch field, unless I read the man page wrong

You wouldn't have 1.2.2.1 in the branch field for that node. What you
would have is zero or more numbers referring to nodes that start
branches based on that node. Their numbers would be 1.2.2.1.X.1 where X
is some even integer.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Removing Files on Tags

[Kaz Kylheku]

On Wed, 18 Jun 2003, Mischke, MaryBeth wrote:

>  I've seen the subject of CVS allowing files to be removed from tagged
> versions (as opposed to forcing you to create a branch to modify instead)

If you are talking about removing a file that has a sticky tag, no this
is not allowed. You get a message like: ``cannot remove file 'foo.c'
which has a numeric sticky tag of 1.1''.

> kicked around in a few other messages from a couple years ago.  Does anyone
> know if there has been an update on this lately?  From what I can tell that
> is still the default behavior.  The only way I can find to get around it is
> to disable permission for users to remove files through an access control
> list, but that is problematic as there are files that users need to remove

What? Removing an object in CVS causes new information to be recorded in
the history file. It does not constitute removal of the history file
from the repository. So to prevent a CVS remove at the operating system
level, your access control list would have to deny writes, which would
prevent users from changing the file in any way, or even recording new
tags.

> from non-tagged versions.

Or, in general, if some software allows something dangerous to happen,
you could get intelligent users who are capable of following 
``don't do that''-type instructions.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Using dos2unix on commit???

[Kaz Kylheku]

On Fri, 13 Jun 2003, Andy Kriger wrote:

> I am trying to setup our Unix-based CVS repository to run dos2unix when
> files are committed, but I'm not having much luck and don't see any solution
> laid out clearly in the mailing lists.

CVS in client-server mode already performs the conversions.

(You aren't doing anything silly, like mounting the repository as a
filesystem over the network?)



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Mergening into multiple branches

[Kaz Kylheku]

[EMAIL PROTECTED] (Peter S. Shenkin) wrote in message news:<[EMAIL PROTECTED]>...
> "Boris Tabenkin" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> > Hi all,
> > 
> > I am new to cvs. We are trying to find a way that a file that is the same in
> > multiple branches can be updated in these multiple branches without having
> > to be merged by hand. The scenario is this. When a release is shipped a
> > branch is made. In the future a bug is discovered in that old release. Now
> > when the bug is fixed we want the change to propagate to that branch and to
> > the head of the tree.
> 
> I've not found a way to do this, though mcvs (Meta-CVS) is said to
> be able to automate this process.

To clarify, Meta-CVS automates the branching and merging capabilities
inherent in CVS; it does not currently extend the model to support
``wrong way'' merges (to borrow Brad Appleton's term). You would still
want to fix the bug in the branch corresponding to that old release,
and merge it properly to the trunk.

The difference is that this Right Thing is easier to do, so you don't
have to look for more convenient workarounds:

  mcvs sw old-release-branch
  # fix bug in old release
  mcvs ci  # commit
  mcvs sw  # switch to trunk
  mcvs merge old-release-branch
  # resolve any conflicts, commit

There are a number of difficulties to overcome in order to support
any-to-any merging, so I have shelved it for now.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: A series of CVS questions.

[Kaz Kylheku]

On Thu, 5 Jun 2003, Sam Talebbeik wrote:

> Folks,
> 
> I have a long list of feature questions about CVS. I have used CVS on a
> previous project years back. I am currently using a "commercial" product 
> in my present project. I would like to know if certain features of 
> this "commercial" product are or will be available in CVS.
> 
> Is this the right forum to ask these questions ? 

CVS is thoroughly documented; questions like does CVS do this or that
are explicitly or implicitly answered in its manual.

The Usenet newsgroup comp.software.config-mgmt is a suitable forum for
version control system comparisons.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: .cvsignore file being ignored

[Kaz Kylheku]

On Thu, 5 Jun 2003, Peschko, Edward wrote:

> >> If we don't want .exe files in the repository, the add command should defend that 
> >> decision for us, even if weakly.
> 
> > I happen to disagree strongly . . . There's nothing I hate more than software that 
> > knows
> > more than I do.. etc. etc. etc
> 
> But that's what I don't understand. The idea behind .cvsblock (or TYPES or whatever) 
> is to be able 

I think that .cvsblock is silly; the tiny semantics difference between
that and .cvsignore is not worth it. The cvs add command should ignore
things that match .cvsignore, period. Those who disagree: what part of
``cvs'' and ``ignore'' isn't clear?

An interactive error would be a reasonable compromise. The software
notices that the user requested to add files which match the .cvsignore
specification, and so brings up a menu: add this file anyway, skip it,
apply this action to all the rest.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: .cvsignore file being ignored

[Kaz Kylheku]

On Wed, 4 Jun 2003, Peschko, Edward wrote:

> No need for mediation. The point of .cvsblock would be to scan, and filter, 
> arguments on the 

You want it, you hack it!

Meta-CVS works as you want. It has a TYPES file which can specify that
files having a certain suffix ought to be added using a given CVS
expansion mode, or that they should be ignored.

This is honored for every file that is passed as an argument to ``mcvs
add''. If you do ``mcvs add foo.o'' and .o files are to be ignored,
nothing happens.

This is as it should be. The TYPES file represents the project's
policy; some random user command should not override that policy. If we
don't want .exe files in the repository, the add command should defend
that decision for us, even if weakly.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: merging changes....

[Kaz Kylheku]

On Wed, 28 May 2003, Greg A. Woods wrote:

> [ On Wednesday, May 28, 2003 at 08:57:59 (-0700), Kaz Kylheku wrote: ]
> > The only reason for not doing so is the psychological barrier created
> > by an awkward manual system.
> 
> Nope, that's not the problem AT ALL.  NOT ONE BIT.
> 
> What people need to learn is the difference between "merging changes"
> and the different levels of assistance any one given tool can provide
> for merging of changes.  No merge tool can ever guarantee 100% perfect
> merges unless it is as smart as the whole programming team combined, as
> well as having the specific skills of the compiler parser.

Lower and lower levels of assistance create increasingly tall
psychological barriers.

> Coding style (code layout, naming conventions, etc.) is by FAR the most
> important factor affecting the ease of merging with any tool using
> diff/patch to merge changes.

It's only an important factor when it's missing. When you achieve good
layout, conventions and so forth, then what was previously the second
most important factor affecting the ease of merging becomes the number
one factor.

> Programmer incompentency is the biggest psychological barrier to
> merging. Anyone hung up on how to use their tools is already heading
> down the wrong path and must backtrack to learn the basic skills of how
> to copy changes from one place to another and how to resolve inherent
> conflicts before they'll ever be able to successfully use any tool to
> assist them in making merges easier.

I have the skills already to compensate for the lack of assistance from
the tools. I just don't want to exercise those skills, because it is
boring and mundane to do so. 

Laziness, not stupidity, is the psychological barrier---the natural
resistance against doing something tedious that ought to be done by the
machine.

I enjoy doing something manually only as a means to discover the
algorithm. Once I have a ``script'' for doing it, I'm no longer
interested in serving as the machine for executing that script.

> So long as good coding style is enforced for a project any well trained
> programmer will be able to select and merge changes with ease even with
> the most primitive of tools.

Indeed, after spending a lot of time and keystrokes. The most effecting
training method for that is the extraction of brain tissue from the
frontal lobe.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: outsider's perspective

[Kaz Kylheku]

On Tue, 27 May 2003, Greg A. Woods wrote:

> No concurrent versioning system with a shared repository, and
> particularly not one that can operate in a client/server mode, can ever
> possibly make any use of ownership, nor even of most permissions bits.
> Ownership information, and most permissions bits, "MUST" always be
> specific to the client and it MUST NOT be dictated by the repository.

I agree. By definition, nobody should ``own'' any file in a project.
Files are there so they can be shared and worked on by many people.
In version control, access control makes sense at the granularity of a
whole project: who gets read access to the whole thing, and who gets
read-write.  A versioned tree is effectively one object.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs add

[Kaz Kylheku]

On Tue, 27 May 2003, Greg A. Woods wrote:

> [ On Tuesday, May 27, 2003 at 09:29:13 (-0700), Paul Sander wrote: ]
> > As for the "rarity" of having to review the history of any given file,
> > that's just bogus.  My users review the history every time they perform
> > a merge.
> 
> Perhaps your users are forced to merge too often because they're working
> in a poorly engineered project.

In my Meta-CVS project repository, I have a stable branch and the trunk
(with some things named differently). I merge to the trunk after every
single commit to the stable branch.

I just switch to another sandbox which is updated to the trunk, type
``mcvs merge mcvs-1-0-branch'', resolve any conflicts and commit.

You want to merge early and often, in the spirit of continuous
integration.

The only reason for not doing so is the psychological barrier created
by an awkward manual system.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: outsider's perspective

[Kaz Kylheku]

On Tue, 27 May 2003, Steve deRosier wrote:

> Also, if so many people NEED this functionality, why doesn't it get 
> added to CVS? 

One reason is that it doesn't have to be literally added into the CVS
program, but rather imposed on top of it. CVS can be used as a
subprocess in a version control system that has the functionality.
This is a legitimate way of creating a ``CVS II''. In fact, this
approach is better in many ways than hacking inside CVS.  Separate
processes provide fault isolation, and avoid forking the codebase. If
``CVS II'' has a bug that stems from CVS, you just upgrade CVS to the
bugfixed version. It's blackbox inheritance! CVS gives us the ``base
class'' which we ``override'' to the get ``CVS II'' behavior with
versioned directories, symbolic links, permissions, etc.

There are a few drawbacks. The command line interface sometimes is less
than ideal, and also systems impose limitations on its length, so the
``CVS II'' layer sometimes has to break up long command lines, turning
one logical CVS operation into multiple actual ones.  Another problem
is that the output of the CVS process sometimes has to be passed
through a text filter so that it makes sense at the ``CVS II'' level.
Doing the substitutions in CVS itself would mean altering its code.

``CVS II'' has already been written, and released almost 1.5 years ago,
but you see, it was unfortunately named ``Meta-CVS'', and so people
somehow don't see it as a proper sequel.  If the sequel to The Matrix
was called ``Riemann Sphere'', perhaps few would get it either.

Meta-CVS does directory structure versioning, and other things. but
it's not CVS II!  Why? Because it's not *called* CVS II, and besides,
it's not backward compatible.  Never mind that it uses CVS for
everything: branching, merging, diffing, annotating, viewing logs etc.
and that it's nearly command-for-command compatible. What it stores
in the CVS repository can't be grokked by CVS I clients. (Just like
ANSI C programs can't be grokked by K&R compilers; are those programs
not written in C?)

Okay, so if this is not legitimate, let's hear a concrete plan about
how CVS can be extended to make a ``CVS II'' which is completely
backward compatible with CVS I clients, and works as well as Meta-CVS.
Better yet, let's see some code. It's not enough to propose alternative
ideas when the existing idea is already coded. The CVS mailing list has
seen more than a *decade* of idle discussions about this subject already.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: outsider's perspective

[Kaz Kylheku]

On Tue, 27 May 2003, Phil R Lawrence wrote:

> Date: Tue, 27 May 2003 10:16:00 -0500
> From: Phil R Lawrence <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: outsider's perspective
> 
> On Tue, 27 May 2003 14:24:50 -0400
> Donald Sharp <[EMAIL PROTECTED]> wrote:
> 
> > Have you looked at subversion?  Or what about bitkeeper?
> > 
> > I'm pretty sure that subversion can handle directory versioning.
> 
> Yeah, subversion looks promising, but symbolic links aren't slated
> for inclusion untill after version 1.0, and I didn't see anything about
> Hard links.

When I heard that the SVN guys were planning symlinks, I took the two
days of effort to put them into Meta-CVS. It took some huffing and
puffing, but it was worth it. I ended up using them in a couple of
projects.

Meta-CVS could in principle support hard links as well. I can visualize
quite crisply how it would work, but I currently have no incentive to
do the work.

If I think that something is useful to the product (i.e. *I* can use it
myself, or it provides some strategic advantage) then I might put it
in.

It shouldn't take more than around four 40 hour developer-weeks to do
it (and I mean do it right, so that every operation is properly aware
of hard link support, including ``mcvs grab'').



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: outsider's perspective

[Kaz Kylheku]

On Tue, 27 May 2003, Steve deRosier wrote:

> Alternatively, since you're a Perl programmer, why not just write a 
> simple script to parse the directories.  You could write two scripts:
> Script1.pl -> This one recursively parses the directories, writing a 
> file (or to stdout) a representation (in text, best if easily human 
> readable) of the directory structure.
> Script2.pl -> This one parses the representation file and creates the 
> directory structure.
> 
> The representation since it is in text _could_ and in this scenario 
> _should_ be checked into CVS and properly versioned.

Or you could just Meta-CVS, which has been out well over a year.

You have the basic idea right, but it takes more than a handful of perl
scripts to make robust, smooth version control application that takes
care of the corner cases and error situations.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Exporting (best practices)

[Kaz Kylheku]

On Fri, 4 Apr 2003, Tumy, Brad wrote:

> We are developing a web application and our current configuration requires
> that we "export" the CVS repository to the test server ($WEBROOT under
> Apache) so that we can update and our testers can access the latest code.
> The only way I have been able to ensure that all documents are updated is to
> do a "rm -R *" in the $WEBROOT directory and then export to that directory.
> Is there another way to do this without removing all of the existing files
> first?

You could ``cvs update'' some sandbox to a specific revision, and then
use rsync to synchronize it to the target location, so that only things
that changed are copied over. There is probably a way to tell rsync not
to copy the CVS/ directories.

Scanning the rsync man page, I see that it not only has an exclude
option similar to that of GNU tar, but also a way to exclude files in a
similar way to what CVS ignore does.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: OpenSource CVS-related project Needs Developers!

[Kaz Kylheku]

On Thu, 3 Apr 2003, Greg A. Woods wrote:

> [ On Thursday, April 3, 2003 at 11:00:59 (-0800), Christian Bryant wrote: ]
> > Subject: OpenSource CVS-related project Needs Developers!
> >
> > 
> > http://asmai.sourceforge.net/
> > 
> > Please take a look and email [EMAIL PROTECTED] if you are interested.
> > We are trying to get the project underway and a version out by the end of
> > the year.
> 
> Why don't y'all just learn to use Emacs and its PCL-CVS front-end to CVS?
> 
> Seriously.

And if you want stupid dialog, then use M-x doctor. ;)



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Ignore local changes?

[Kaz Kylheku]

On Wed, 2 Apr 2003, Larry Jones wrote: 

> Date: Wed, 2 Apr 2003 14:01:30 -0500 (EST)
> From: Larry Jones <[EMAIL PROTECTED]>
> To: Eric Siegerman <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: Ignore local changes?
> 
> Eric Siegerman writes:
> > 
> > CVS should probably print a warning in this case, but it doesn't.
> 
> "This case" is updating a file with a sticky tag or date, which seems
> like a good idea to me, too.  Anyone disagree?

I agree conditionally. 

If you have many files (for instance all of them!) sticky to a
revision, you don't want a separate warning for each file. What if they
are all sticky?

Proposal: issue a warning only for those files which are sticky to
something different from what their containing directory is sticky to.

Examples: 

1. The directory ``x'' is sticky to ``foo_branch'' but files ``x/a'' and
``x/b.c'' are sticky to versions 1.3 and 1.9 respectively. The update
operation over the directory warns in this case for these two files.

2. The directory ``x'' is sticky to ``foo_release_1'' but files
``x/a'' and ``x/b.c'' are not sticky to anything. Update over the
directory does update these two files, but produces a warning.

3. The directory ``x'' on the main trunk, but files ``x/a'' and
``x/b'' are sticky to ``foo_branch''. Update warns for both.

4. The directory ``x'' is sticky, and ``x/b'' is
not sticky. The user selectively updates ``x/b''. No warning.

5. The directory ``x'' is sticky to something, and ``x/b'' is
sticky to something else. The user selectively updates ``x/b''. No warning.

6. The directory ``x'' is not sticky, and ``x/b'' is
sticky. The user selectively updates ``x/b''. No warning.

7. The directory, and all its files, are sticky to the same tag,
``release_1_0''. Update does nothing, and produces no warning.
Alternative: update warns that nothing is being done because
of the sticky tag.

Basically any situation in which the stickiness of a file contradicts
the stickiness of the directory should be a cause for warning on
update.   A commit, if otherwise allowed, should probably fail because
of this: the user should be forced to commit the differently-sticky
files individuall.

Example:

8. The directory ``x'' is sticky to branch ``foo'' and ``x/b'' is
sticky to branch ``bar''. User commits in the directory. The commit
fails, explaining the stickiness conflict---that the commit would
be split into two or more branches.

9. The directory ``x'' is sticky to branch ``foo'' and ``x/b'' is
sticky to branch ``bar''. User commits ``x/b'' selectively.
The commit proceeds normally.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Files beginning with a minus sign

[Kaz Kylheku]

On 28 Mar 2003, Ronald Petty wrote:

> What about 
> 
> cvs commit "-filename.txt"

The " " characters are not part of a command line argument; they
are just lexical syntax processed by the shell, affecting how it
tokenizes the command line, and also affects the semantics of
certain expansions. For example, in a script or shell function,
the syntax:

  "$@" 

will expand the arguments such that quotes are placed around each
one. Thus that the command line structure is preserved when the
result of the expansion is re-tokenized.

The token "-abc" means exactly the same thing as -abc .



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS diff of tip vs. checked out

[Kaz Kylheku]

On Fri, 21 Mar 2003, richard blair wrote:

> Date: Fri, 21 Mar 2003 09:53:05 -0700
> From: richard blair <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: CVS diff of tip vs. checked out
> 
> I check out version 1.3 and make edits in my own sandbox version.  Then 
> someone else checks in 1.4.  When I do a cvs diff, it just tells me the 
> diff between my changes and 1.3, and not the tip which is 1.4.  Is there 

That is correct; this is the right behavior that you want 99% of the
time, so that you can review the changes that you made against the
revision you started from.

> a way to do a cvs diff with the tip, whatever it may be?  I know I can 
> specify revisions, but would like to skip having to do a cvs log to find 
> out what the tip is.  Any suggestions?

 cvs diff -r HEAD file   # on main trunk
 cvs diff -r branch-tag file # on branch ``branch-tag''

These tags are what always identify the tip.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: MFC'ing

[Kaz Kylheku]

"Philip M. Gollucci" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> Thanks in advanced. Sorry for the crosspost, but I know some of you FreeB
> SD 
> developers do this all the time.

But this is a CVS newsgroup/mailing list, not a FreeBSD forum. The
term MFC means nothing here, but looking up a FreeBSD FAQ reveals
that:

  16.15. What does MFC mean?

  MFC is an acronym for ``Merged From -CURRENT''. It is used in
  the CVS logs to denote when a change was migrated from the
  CURRENT to the STABLE branches.

In other words, it denotes a merge in the wrong direction (from a CVS
perspective). To the rest of the world, MFC either means nothing, or
stands for Microsoft Foundation Classes, a proprietary C++ framework
for GUI development on Windows. :)

Don't assume that everyone understands your tribal acronyms.

CVS has little support for this MFC'ing. Suppose that a feature is
developed on the trunk, and that feature consists of multiple commits
over many days. Those commits will be interleaved with other commits
done by other people that have nothing to do with that feature. To
create a patch, you will have to unravel your changes from among those
irrelevant ones manually.

If you suspect that a feature you are doing on the trunk may be of
interest to other lines of development* then you should represent it
as its own branch, with a tagged branchpoint and all. Such a feature
isolation branch is simple to merge  wherever you want.

---
* ``line[s] of development'' is a trademark of Shi^H^H^HBitMover,
Inc., makers of the BitKeeper version control system.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Checkout + filename change

[Kaz Kylheku]

On Tue, 4 Mar 2003, Eric C. Hein wrote:

> I have a file "foo" that I want to checkout of CVS.  I also need to
> checkout an older revsion of foo that I would like to place in the same
> directory but not overwrite the first copy of foo.

> Is it possible to checkout "foo" and have it placed in the subdir
> under the name "bar"?

cvs update -r  -p foo > subdir/bar



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Commit inconsistency: Up-to-date check did not fail thoughitshould have !

[Kaz Kylheku]

On Mon, 3 Mar 2003, Mike Castle wrote:

> >- User B commits his changes to p, without first updating his working copy.
> >Against all expectations, user B succeeds to commit even though his working
> >copy is not up to date, leading to an unstable latest version of the project
> >in the repository.
> 
> Hmm... originally I was wondering, "How would this create an unstable
> latest version?"
> 
> The only scenario I can think of is where user B starts making use of a
> function that user A has changed/removed, and that function had never been
> used in that file before.

B could merely start making use of *semantics* which have been changed
or removed, but which are not reflected in any syntactic change.

Anyway, just because there is only one case in which some logic
provides value doesn't mean that you don't have to care about that
case.

In software there are often many special cases, which are handled by
logic which is unique to those cases. Any instance of such logic,
considered by itself, seems to provide little benefit---it just handles
this one silly case!

But working software is the sum total of all those little cases,
frequent ones and rare ones, being handled right, all the time.

Without solid statistical data, or other rational basis, you can only
guess about how frequently a case arises, so that you can make the
argument that handling that case is not worth the extra cost incurred
at other times when that case does not arise.

Maybe semantics changes that preserve the interface syntax do happen a
lot. Programming languages help detect syntactic breakages, after all,
but are not as helpful with semantic breakages. Changing the name or
syntax of an entity to reflect a semantics change is a pain for the
developer, because it requires lots of editing everywhere. 

So I suspect that semantics-warping without syntactic changing goes on
quite frequently; it's the easy, lazy thing to do, compared to properly
versioning the interface and semantics of something, whereby you invent
a new name if it doesn't work like the old one, and keep the old one
around for backward compatibility and all that.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: What is a good Windows CVS client?

[Kaz Kylheku]

[EMAIL PROTECTED] (Sandeep Gupta) wrote in message news:<[EMAIL PROTECTED]>...
> We have a repository that is 124MB of ,v files.  The checkout is 92MB.
> The server is running on Redhat 8.0 with CVS version 1.11.2.
> 
> All clients are using pserver.
> 
> A checkout from a Redhat 8.0 client takes 30 - 45 seconds for a clean
> checkout (no preexisting files on the local machine)
> 
> A checkout on Windows XP using cvs.exe from cvshome.org takes over 3
> minutes for a clean checkout!
> 
> We tried using cygwin's cvs and it is about 25 - 50% faster.

It's unsurprising that a POSIX program ported straight to an
independently developed, properly done POSIX layer performs better
than a version of that program hacked to directly target the platform.

(By the way, what do you mean by 50% faster? 50% faster than 3 minutes
is 2 minutes).

> Why are the Windows XP clients so much slower?

Because Windows XP is a poorly implemented, slow operating system
kernel with sluggish filesystem operations?
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Running CVS on AIX

[Kaz Kylheku]

On Tue, 25 Feb 2003, Lynch, Harold wrote:

> You need to do a couple more things when installing the server as IBM
> "allocates" the 2401 port for there own use. 

Obviously, only if you care about using the pserver protocol.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Migrating from VSS

[Kaz Kylheku]

Murali Potla <[EMAIL PROTECTED]> wrote in message 
news:<[EMAIL PROTECTED]>...
> Hi there, 
> 
> I am migrating a repository from vss to cvs.
> 
> But the important feature that i should provide is file locking when
> some one is editing it so that atleast others will not be able to edit
> it. And all of the files are binary files (microsoft word document). How
> to handle it.
> Is there any good way. 

There is a mechanism in CVS which promotes communication among the
users, so that they become aware of situations when two of them want
to edit the same file, with the help of electronic mail notifications.
This is implemented by the commands cvs commands edit and editors.

This is not strict locking; it requires user cooperation. Firstly, a
user has to use the watch add command to request to be notified about
actions, such as someone's intent to edit (which that user indicates
using cvs edit). Secondly, the user has to pay attention to the e-mail
notifications and/or look at the list of editors to discover who else
may be wishing to edit a file. There can be more than one user ID in
the list of editors; it's not exclusive!

Also, a special watch mode can be turned on for a file to help enforce
the protocol, using ``cvs watch on''. This marks a file such that when
it is checked out, the working copy is read-only. This reminds the
user to use ``cvs edit'', which will make the working copy read-write.
But this can be defeated by manually changing the permissions.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Commit inconsistency: Up-to-date check did not fail though itsho uld have !

[Kaz Kylheku]

On Wed, 19 Feb 2003, Fabian Cenedese wrote:

> Well, I also commit single files for the same reasons (even if that makes
> me an idiot too). But before committing I sure do a test/update if there
> has anything changed in the repo. So I do the same as cvs ci on whole
> sandbox, just manually. 

I believe that it is not the same thing. The cvs ci operation is an
atomic test and set: it acquires a lock over what you are trying to
commit, checks that it's up to date, and then if so, it completes the
commit before releasing the lock.

Doing a separate update operation just before a selective commit
creates a race condition because the lock is not maintained across
both operations; you are thus relying on winning a race, however great
the odds may be in your favor due to the small time window.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Commit inconsistency: Up-to-date check did not fail though itsho uld have !

[Kaz Kylheku]

On Wed, 19 Feb 2003, Ludvig Borgne wrote:

> > Just go to the highest relevant directory and type ``cvs ci'' with no
> > arguments, or at most a -m to specify the message.
> 
> Hmm, this is interesting. I have always been (and still am) of the
> opinion that one should always commit individual files, and never ever
> do a 'cvs commit' on the top level of a module. Why? Because top level
> commits usually create poor log messages (same for all files), and

A log message that is the same for all files is not necessarily a poor
log message, and separate messages are not necessarily better.

Look at how ChangeLogs work. There is one entry, with a date, and the
author's name, and then descriptions of all the changes, file by file.

It's useful for a comment to gather together all related changes in one
description. If I'm browsing the history of foo.lisp, it's useful to know
how some change correlates with something in bar.lisp.

If you don't commit often enough, however, you can get into the
situation where your tree contains many unrelated changes, which should
not be described by one comment.

I combat this effect by keeping more than one sandbox for isolating
changes, but it's not always convenient.

> because it makes it far too easy to commit files that you have just
> made temporary modifications to (e.g. changing a make file to compile
> with debug flags) that you really don't want to commit at all.

Maybe your local copy of the software works only because you made these
local modifications, so that if you don't commit them along with your
``real'' changes, it will break for someone else. The other developers
may be building without the altered Makefile.

Note that if you have to change your Makefile to make a debug build,
and if changing the Makefile results in a local modification to a
sandbox file, you have a few ugly warts in your project setup.

Firstly, a nice Makefile can be constructed which will build multiple
configurations of the same software: debug, optimized, profiling, ...

On one project I worked on, six different configurations of the same
thing were compiled. I set it up so that the object files were all
dropped into the same directory, but with alternate suffixes: .o was
native optimized, .d debug, .armo was optimized, cross-compiled for
StrongARM, etc.

Secondly, if you must locally edit Makefiles, then it's probably a good
idea to actually store them in CVS under a different name, requiring
everyone to make a local copy, use a symbolic link, or invoke ``make''
with the right argument to point to the file. This becomes quite handy
if you ever need two or more different makefiles, to accomodate
incompatible make programs: e.g. Makefile.gnu, Makefile.vc.

> Oh well, I guess I must be a total idiot then...

You *can* commit individual files, if you are certain that your changes
preserve the relationships between those files and the rest of the
project.

Say you have some ``foo.c'' in which you change something in the foo()
function without changing its interface, or semantics.  Sure you can
commit that on its own.

Say that instead, you change the foo() interface or semantics, or
extend them in some backward-incompatible way, and fix all uses to
foo() that you see in your working copy to match the new version. You
shouldn't commit those files individually, because someone may have
commited a change elsewhere which introduces a new dependency on that
function's old interface or behavior.

You can also get away with individual commits most of the time, if you
remember to do a whole-tree update just before. Then you are
essentially racing to do a commit before any new changes come in that
will break it. If you win the race most of the time, you are okay most
of the time. ;)



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Commit inconsistency: Up-to-date check did not fail though itsho uld have !

[Kaz Kylheku]

"Reinstein, Shlomo" <[EMAIL PROTECTED]> wrote in message 
news:<[EMAIL PROTECTED]>...
> - User B commits his changes to p, without first updating his working copy.
> Against all expectations, user B succeeds to commit even though his working
> copy is not up to date, leading to an unstable latest version of the project
> in the repository.

User B is an idiot for not performing a commit over the entire tree
which is affected by his change, and for having unrealistic
expectations on what a single-file commit ought to do.

Just go to the highest relevant directory and type ``cvs ci'' with no
arguments, or at most a -m to specify the message.

In Meta-CVS, if you do a ``mcvs ci'' with no arguments anywhere in the
tree, it will commit on the entire project, directory structure, files
and all. The tag and update commands work similarly.

The only way to say ``commit (or update or tag) this directory only''
is to specify the single parameter .

The other commands like log and diff work just on the current
directory and its subdirectories when no arguments are given.

This design is deliberate; it promotes consistency. If you make it
awkward for people to achieve consistency---by for instance forcing
them to ``cd'' to some higher directory to do a commit---they will
fail to do so, at least some fraction of the time.

> - The repository is on NFS.

In related news, user B's CVS administrator is also an idiot.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Why is this file stuck in the Attic?

[Kaz Kylheku]

[EMAIL PROTECTED] wrote in message 
news:<3e4bf732$1$fgrir53$[EMAIL PROTECTED]>...
> Hi,
> 
> I have an associate that managed to get some files stuck in the Attic and
> I want to be sure I explain the reason correctly.  I've appended the
> interesting parts of the history and log commands.

This is some kind of bug. The file was clearly resurrected, acquiring
a non-dead revision on the main trunk. This should have been
accompanied by a move out of the Attic.

> My interpretation is that at revision 1.7, the file was deleted and moved
> to the attic by one user.  The second user then explicitly pulled a copy
> of the "missing" file, made changes and checked the changes in.  This file
> stayed in the Attic, as it should have, and remained invisible to normal
> cvs checkout and update commands.  Is this correct?

A dead file can, in principle, be only resurrected by a ``cvs add'' on
an object having the same path name. It sounds like the resurrection
somehow happened differently, as a result of a race condition between
a delete done by one user and a commit done by another. This is one of
those corner cases of CVS that this page refers to:
http://users.footprints.net/~kaz/mcvs.html.

> What I don't understand is why the state for revision 1.8 and so on did
> not remain dead.

A dead state is the result of a commit after ``cvs rm''. There should
not be a sequence of dead states; if any new revision is created in
sequence after a dead state, it should be a non-dead state, because
the only reason for creating a new revision would be to resurrect the
file.

You should repair this situation by moving the file manually out of
the Attic. Also note that the file *will* be checked out if you use a
-r option to select a revision. To check out the main trunk, you can
use this:

   cvs co -r HEAD ...

when you run CVS this way, it ignores the Attic optimization, and
looks into the Attic directories to find all files.

I think that this should become the default behvior of CVS; the Attic
optimization should be deprecated, and eventually scrapped. CVS should
continue to understand and process the Attic directories for backward
compatibility, but not generate them.

The whole reason for Attic directories is to shorten the directory
scan times when updating or checking out the main trunk. More
importantly, Attic eliminates the need to open an RCS file, parse it,
and determine its head revision, only to find that the state is dead.
This optimization could be achieved without the Attic directory: a
cache structure could be kept somewhere in some text files which would
tell CVS what files to ignore because they are dead on the main trunk.
Such a cache could just be blown away if it was suspected that its
contents are misleading.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: tagging local copy

[Kaz Kylheku]

Bill Lynch <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> All,
> 
> I forgot to tag some work of mine 2 days ago and I'd like to go back and tag it. 
> I haven't touched my local copy since but I know a couple of other people have 
> checked in changes since. If it run a tag command against my local copy, will 
> that tag using the versions of the files locally or the versions that are latest 
> in the repository (ie, the other people's work)?

The tag is applied in the repository, to the versions which your
working copy is based on---i.e. the versions that are recorded in the
CVS/Entries and reported by cvs status as the ``Working revision''.
Thus after you commit your work, you can tag what you did without
worrying that there is any race against other commits. As such, the
time interval then doesn't matter. Whether you tag a second later, or
three weeks later, there is no difference---as long as you don't
update your working copy to pick up newer revisions!
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS/Root should record the CVS_RSH environment value...

[Kaz Kylheku]

On Tue, 4 Feb 2003, Greg A. Woods wrote:

> Date: Tue,  4 Feb 2003 14:19:34 -0500 (EST)
> From: Greg A. Woods <[EMAIL PROTECTED]>
> Reply-To: CVS-II Discussion Mailing List <[EMAIL PROTECTED]>
> To: CVS-II Discussion Mailing List <[EMAIL PROTECTED]>
> Subject: CVS/Root should record the CVS_RSH environment value...
> 
> It is _VERY_ unfortunate that CVS/Root does not record the setting of CVS_RSH.

What's unfortunate is that the repository identification syntax does
not experss the protocol, so you have to use the CVS_RSH hack to do so,
relying on command compatibility of ssh and rsh. Then the purpose of
CSV_RSH would be relegated to selecting an alternate rsh
implementation, not to switch to a different rsh-compatible transport.

An extension along the lines:

  :ext-rsh:user@host:/path/to/repo
  :ext-ssh:user@host:/path/to/repo

could be the thing.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: use '-d' option

[Kaz Kylheku]

On Mon, 3 Feb 2003, Monica Li wrote:

> I imported some files into repository and checked out file for updating. It
> was all ok last week. Today, when I login I typed:
> 
> cvs -d :pserver:userName@cvsserver:/repository login
> Logging in to :pserver:userName@cvsserver:2401/repository
> CVS password
> 
> After login, I didn't do anything and logout. The following msg come up:
> 
> cvs logout: No CVSROOT specified!  Please use the `-d' option
> cvs [logout aborted]: or set the CVSROOT environment variable.

You still need a CVSROOT environment variable or -d option, even though
you logged in. Logging in just means that a weak security token is
deposited into a file in your home directory, which allows you to
interact with the repository. 

The key fact here is that you can log innto more than one repository at
a time; the file can contain more than one such token! There is no
concept of a ``current CVS repository you are logged into''. 

The CVSROOT environment variable, the -d option, or, for many commands,
the surrounding sandbox (checked out copy) determine what repository
you interact with.

The cvs logout command too has to know *which* repository you want to
log out from.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: problems with cvs checkout -d on xp

[Kaz Kylheku]

Pierre Asselin <[EMAIL PROTECTED]> wrote in message news:...
> In <[EMAIL PROTECTED]> [EMAIL PROTECTED] 
>(Phil Radcliffe) writes:
> 
> >[ ... ]
> >- if I cd into c:\tmp mkdir a directory called test1 and then do cvs
> >checkout -d test test-corem then everything is fine - I get the
> >expected files in c:\tmp\test1 and c:\tmp\test1\workflows
> 
> Right.  You should check out into an empty directory.
> 
> 
> >- if however I cd into c:\tmp mkdir a directory test2, cd into test2
> >and mkdir a directory called workflows, the cd backup upto c:\tmp and
> >issue cvs checkout -d test2 test-corem then I dont get the files in
> >the workflows directory.
> 
> Correct.  Don't create the directory hierarchy, let cvs do it.  You're taking
> a chance even when you create the top-level test2/ directory.
> 
> 
> Another warning, just in case I'm guessing correctly what you were going
> to try next:  If you plan to check out several modules like test-corem
> and prod-corem to one and the same corem/ working directory, that won't
> work!  It is a fundamental limitation of cvs that all the files in a
> sandbox directory must come from the same repository directory.  If you
> can't change your plans to live with that, you need a different tool.
> Possibly Meta-CVS.  (Kaz, is there a Windows client?)

Meta-CVS runs on Windows in the Cygwin environment. Obviously, you
need to install the CVS package and it doesn't hurt to have some kind
of text editor. ;)

I have Cygwin binaries on the web page; to use these you just unpack
the tarball relative to the root directory, and it sticks things in a
few places in usr/local/*.

Meta-CVS won't *quite* solve the above problem, however; that is to
say, it also has the limitation that a directory comes from one
repository (and you bet that checkout tests for this and refuses to
check out over an existing sandbox).

However, a Meta-CVS sandbox has an administrative file only at the top
level. What this means is that inside *subdirectories* of the sandbox,
you can check out other Meta-CVS sandboxes. A MCVS directory will be
created at that level, and when you type mcvs commands at that level,
or lower, the search for the MCVS directory will terminate there,
because it proceeds from leaf to root. So what I'm saying is that your
mcvs actions in the nested sandbox will be ``scoped'' to that sandbox.
Files from the enclosing sandbox will appear to be local files that
are not known to the enclosed sandbox.

This trick is not possible in CVS, because it sticks admin directories
at every level. However, you could patch CVS to rename those admin
directories; the you could switch the context via some environment
variable to say whether you want to talk to the nested CVS checkout or
the enclosing one.

Checking out into an existing local tree is fine in Meta-CVS by the
way, with a few caveats: if some local files conflict, you are taken
to an interactive error handler which lets you clobber the local
files, or leave them alone (so they effectively become working edits
relative to the repo). While this is superior to emitting ``move
blah.c out of the way'' and aborting, it's not fine-grained enough.
There is a TODO item to give the user the option of going through the
conflicting files one by one and choose which way to clobber. If
someone wants this badly enough, and know Lisp well, it's probably one
hour away. Patches welcome.

Speaking of nested sandboxes, I have vague plans to steal a Subversion
feature: namely storing module definitions as special items in the
mapping file. Module definitions would cause the recursive checking
out of specified modules under specified directory names. It would not
be implemented as a special property on a directory object, because
Meta-CVS does not represent directory objects. However, modules could
be simply represented as special items. Right now the only items are
:FILE and :SYMLINK. This would add a third mapping item called :MODULE
with its own properties.  Modules would have to be handled specially
on renaming; this is potentially a very tricky issue. You can't hard
link to directories, but a workaround might be to check out the
submodule under a cryptic directory in the MCVS directory, and then
plant that submodule into your tree as a symbolic link to that thing.
This way, for instance, if you do an update, and someone has removed a
module, Meta-CVS doesn't have to blow that module away. It just blows
away the symbolic link. This makes messy problems go away; because one
sandbox doesn't really have the jurisdiction, so to speak, to blow
away another. The ``mcvs purge'' command could be extended to hunt
down submodules that are not symlinked from your sandbox and remove
them, putting control into the user's hands.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Branch aliasing

[Kaz Kylheku]

"Simon Scott" <[EMAIL PROTECTED]> wrote in message 
news:<[EMAIL PROTECTED]>...
> Hi,
> 
> Please could I ask for any advice on the following.

[ Snip: description of scheme whereby branches are partially aliased:
in one subtree of the project, branch tags A and B are independent
branches. In another subtree, both point to exactly the same branch
numbers in every file, therefore coinciding. ]

I can't think of anything wrong with this scheme, other than this:
people can't independently work on branches A and B for that subtree
where it is aliased. Obviously, this is a ``feature'' of the scheme;
if you thought that this was a problem, you wouldn't propose it.

The aliased part of the tree may well be a highly stable code subject
to careful changes, so that rather than destructive interference
between the A and B streams, there is actually a positive
collaboration from instantly sharing critical bugfixes without having
to merge back and forth.

A variation of this practice occurs when people branch just a subtree,
switch it to that branch, and leave the rest of the working copy on
the trunk. They get their own independent stream over that subtree,
but pick up changes from the trunk whenever they update. This is
almost equivalent to your scheme, except that the trunk is not endowed
with the branch tag, so the checkout cannot be done all at once:
others who want to participate in the scheme have to do a full
checkout of the trunk, go to the branched subdirectory and update that
to the branch. If they try to just check out the branch, they won't
get the whole tree because the tag does not exist outside of the
subtree.

This ``lazy branching'' is sometimes done by CVS users, and it works.
I have done it in the past, but usually I followed up on it by adding
the branch tag to the rest of the tree (hence the term ``lazy''
branching). In other words, just branch the part that you need to
branch *now* and then later extend it to the whole tree to make a
proper branch. I did this because I did not need to ``freeze'' the
rest of the project with respect to my changes; it was beneficial to
work in the subtree while integrating with the rest of it by simply
doing updates.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Can I use same tag name on different branches?

[Kaz Kylheku]

On Mon, 20 Jan 2003, Demissie, Yared wrote:

> Date: Mon, 20 Jan 2003 16:44:56 -0800
> From: "Demissie, Yared" <[EMAIL PROTECTED]>
> To: "Chen, Susie" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: RE: Can I use same tag name on different branches?
> 
> It wouldn't let you use the same tag on two branches without over-writting
> the first one, so you would end up with just the last one, in your case b2.

If you tag twice, then CVS emits a warning for all files in which the
tag exists already and leaves it alone.

Suppose b2 contains a few files that are not in b1. 

You do

cvs rtag -r b1 A module

Okay, so all the files at the tip of branch b1 have the tag now. Then
you do:

cvs rtag -r b2 A module

now any files which are present in b2, but not in b1, get the tag. 

There is a -F option you can use to force the retagging.  I *think*
that if -F is combined with -r, this will also *remove* the tags from
files that are not in the new file set. 

I seem to recall that there is a bug with this if there is no -r option
(main trunk HEAD is *implicitly* selected as the revision). Probably
because the Attic optimization is applied. The workaround is to use 
``rtag -F -r HEAD'' when pushing a tag forward on the main trunk, such
that it's correctly removed from any files that were previously
tagged, but have been removed since then.

-- 
Meta-CVS: directory structure versioning; versioned symbolic links;
versioned execute permission; versioned property lists; easy branching
and merging and third party code tracking; all implemented over the
standard CVS command line client -- http://freshmeat.net/projects/mcvs



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Can I use same tag name on different branches?

[Kaz Kylheku]

On Mon, 20 Jan 2003, Chen, Susie wrote:

> Date: Mon, 20 Jan 2003 16:31:48 -0800
> From: "Chen, Susie" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Can I use same tag name on different branches?
> 
> 
> I have two branches (b1 and b2) under same module.   I tagged the b1 with A,
> and later tagged b2 with A as well.   If I check out by A later, what set of
> files will be retrieved?

Possibly a mixture of the two, depending on how you tagged. Did you use
tag or rtag? Did you use the -F option or not?

Without -F, tag and rtag do not edit existing tags. But they will still
apply the tag to files that don't have it.

The tag command will only operate on those files that are visible in
your working copy. If you are currently on branch b1, and use ``cvs tag
-r b2 tagname'', then only those files which exist in both b1 and b2
(the intersection set, roughly) will be tagged. You should almost never
use tag with a -r option, but use rtag instead.

So, given these possibilities, you can see how the tag A might end up
being spread between two branches, so that it's on the b1 branch of
some files, and the b2 branch of others.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: update -j updates more than requested

[Kaz Kylheku]

On Mon, 20 Jan 2003, Alicia Jones wrote:

> I have an (untagged) working copy that was originally checked out from
> the main trunk.  More files have been checked into the main trunk since 
> then, so there are files/changes on the trunk that are not in my 
> working copy.  My working copy also has uncommitted adds/changes.
> 
> I now want to merge in the changes from another branch made off of HEAD
> into my working copy.  The branch is further down the trunk than my 
> working checkout, but not at the end of the trunk.

Ah, well, then relative to you, that branch consists of all the main
trunk work up to that branching point, and then all the work on the
branch.

> I expected the following to work:
>cvs update -j BRANCHTAG working_dir
> 
> However, this not only merges in the changes from the branch, but it's
> ALSO brings my working dir up to date with the LATEST (past my checkout
> AND the branch) versions checked in on the main trunk.  I only want the
> changes from the BRANCH, without picking up any changes on the trunk.

In that case, there has to be a branchpoint tag which marks the point
on the trunk where the branch was made. You merge using:

   update -j branch-start-point -j branch

This will do the right thing. If, alas, no such tag was made, you might
be able to approximate it if you can guess the date and time when the
branch was sprouted.

People should practice making branchpoints. Without them, it's hard to
take a branch to be a changeset which can be grafted into distant
places in the revision tree.

> 'cvs update -j NONBRANCHSTARTTAG -j BRANCHTAG working_dir' gives the
> same
> result, which is really strange.
> 
> Anyone know how I can get what I want?   BTW, this is CVS version
> 1.10.7.

You should consider upgrading to 1.11, though not specifically for this
problem. A lot of debugging has happened since 1.10.7.

There was a branchpoint patch floating around to add special syntax for
implicitly referring to the base revisions of a branch, thereby
avoiding the need for a branchpoint tag. I'm not sure whether this has
been rolled into the official CVS sources.

-- 
Meta-CVS: directory structure versioning; versioned symbolic links;
versioned execute permission; versioned property lists; easy branching
and merging and third party code tracking; all implemented over the
standard CVS command line client -- http://freshmeat.net/projects/mcvs



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Help with moving repository

[Kaz Kylheku]

On Mon, 20 Jan 2003, Mark Cooper wrote:

> Is there a utility available anywhere to perform global changes to the cvs
> metadata in a users working copy. For instance change the entry in cvs/root
> from ":pserver:user@oldcvs:/cvs/cvsroot" to
> ":pserver:user@newcvs:/cvs/cvsroot". I can imagine that someone somewhere
> has done this before.

A simple combination of find and sh should do:

find . -type d -name CVS -exec sh -c 'echo :pserver:... > {}/Root' \;

Here's yet another reason to use Meta-CVS: only one CVS directory 
to fiddle with if you ever have to.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS server for Windows: does it exists?

[Kaz Kylheku]

Roger <[EMAIL PROTECTED]> wrote in message 
news:...
> Subversion has a Windows installer, but it requires Apache 2.0 or 

Subversion isn't CVS.

Alberto probably wants version control that is here and now.

> better.  I am still on an older Apache version so I haven't installed 
> it. 

But hey, why wait until then before recommending it to someone else.

> WinCVS probably won't work with it.

Ya think?
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS server for Windows: does it exists?

[Kaz Kylheku]

"Alberto Pellegrini" <[EMAIL PROTECTED]> wrote in message 
news:...
> Hi all!
> 
> Does anybody know where it is possible to download a precompiled CVS SERVER
> for the windows environment?

Try http://www.cvsnt.org

> In case of not availability of this product, how much difficult is to
> compile in cygwin environment the sources of the CVS server? ... or do you
> know a better way to have a WinCVSserver?

Run it on BSD or Linux.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: "Promotion groups"

[Kaz Kylheku]

On Thu, 16 Jan 2003, Paul Sander wrote:

> I implemented such a system using CVS about 10 years ago, and it worked
> quite well.  There has been some discussion about it over time in this
> forum.  Search the archives for "submit/assemble" for details.

Is this something that could would be a wortwhile hack in Meta-CVS?



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Modified file list

[Kaz Kylheku]

On Thu, 16 Jan 2003, Chow, James wrote:

> cvs diff is giving me way too much information for just a file list.

cvs diff takes the same options (mostly) as GNU diff. There is about a
million of them; it's worth investigating their capabilities.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: changelog format

[Kaz Kylheku]

On Sun, 12 Jan 2003, Stefan Bühler wrote:

> Hello,
> 
> how can I build a changelog in the format, like wincvs has (I want to have the 
>information date, revision and log message, without file name and user)
> Until now I used -->TCL Macro  --> Build ChangeLog.
> Installed is W2K SP3, WinCVS 1.3.10.1 build 10, CVSNT 1.11.1.3 build 64.

One way is to use the Perl script written by Karl Fogel, called
cvs2cl.pl. See http://www.freshmeat.net/projects/cvs2cl.pl



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Change history?

[Kaz Kylheku]

On Thu, 9 Jan 2003, Chow, James wrote:

> hi
> 
> Is there anyway for cvs to return a list of changes for the day or week?

Yes; learn how to use the ``cvs log'' command's -D (date) parameter.

There are some utilities that munge the output of CVS log to generate a
more useful report, such as a ChangeLog report. Take a look at, for
instance: http://www.freshmeat.net/projects/cvs2cl.pl



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: new files ending up with state: dead

[Kaz Kylheku]

On Wed, 8 Jan 2003, Tiago Antao wrote:

> Date: Wed, 08 Jan 2003 12:25:18 +0100
> From: Tiago Antao <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: new files ending up with state: dead
> 
> Hi!
> 
> I am a CVS user for a few years now and I have stumbled on a problem 
> that is more or less driving me mad:
> 
> When I add a new file to cvs (or update an old one) it will 
> automatically be put in the attic, so if I do

You are adding on a branch, so the file does not exist on the trunk
until you merge that branch.

> revision 1.1
> date: 2002/10/24 08:46:59;  author: tiago;  state: dead;
> branches:  1.1.2;
 ^
> file cr.c was initially added on branch dbupdate_restructure.
> 
> revision 1.1.2.1
   ^
> date: 2002/10/24 08:46:59;  author: tiago;  state: Exp;  lines: +163 -0
  ^^^



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Variables in sourcecode?

[Kaz Kylheku]

"Patrick Wentzel" <[EMAIL PROTECTED]> wrote in message 
news:...
> This is what I want to do:
> * Store sourcecode (jsp & java) in CVS with variables for things like URLs
> etcetera.

Do a web search for ``macro preprocessor''. It's what every decent
programming language has built-in.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: How is a patch applied to CVS?

[Kaz Kylheku]

On Mon, 6 Jan 2003, Mazza, Glen R., ,CPMS wrote:

> Simple question (I've checked the Cedarqvist manual, it's probably there but
> can't seem to find it!):  How is a patch file committed into CVS to update
> the most recent version?

There is no support built into CVS for doing this. You check out a
working copy, use the patch tool to turn the patch into local
modifications, and then verify and commit the changes.

It probably will behoove you to keep track of the patch levels in a
branch. That way the patch will always be applied against an exact copy
of the baseline from which it was made by the third party developers.

To integrate it into your locally modified verison of the software, you
merge from that branch.

The moral is that it's better to let CVS do the merging, than the patch
tool. It's better at it, having more information. Patch can only do a
two-way merge, having no access to the ancestral version. It bails on
anything difficult, throwing hunks into .rej files.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Vendor Branches

[Kaz Kylheku]

On Sat, 4 Jan 2003, John Birtley wrote:

> Date: Sat, 4 Jan 2003 20:05:46 -
> From: John Birtley <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Vendor Branches
> 
> I wonder if anybody can help me with the following problem regarding
> multiple vendor branches.

Meta-CVS has a feature like vendor branching, but sane. The ``grab''
command is conceptually similar to import, but it uses an ordinary
branch (that you create beforehand). Thus it can keep track of external
patches relative to any baseline you choose. Moreover, grab figures
file moves and renames, as well as symbolic link reconfigurations.
Because Meta-CVS keeps track of repeated merges from the same source,
merging the results of successive grabs is painfully simple:

mcvs grab -r  
# verify renames, look at diffs, etc.
mcvs ci
mcvs sw  # switch to integration branch
mcvs merge# merge from vendor-branch
# resolve conflicts, verify
mcvs ci

Grab doesn't do anything to the repository; it converts your working
directory into a sandbox of the specified module, containing the
would-be import as local changes.

> cvs import 
> cd /tmp
> cvs checkout -jINTEGRATION -rVENDOR_LATEST_ddmm repository
> cvs commit

Merging requires two -j options, except when it's the first time it's
done from a branch to the trunk. You must use tags to keep track of the
last merged point.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Auto merge to Trunk?

[Kaz Kylheku]

On Fri, 3 Jan 2003, Prakash Subramanian wrote:

> I would like files to be merged to trunk whenever files are checked
> in to a particular branch,
> Is there a way to achieve this?
> Basically, the branch I am referring to is the production branch and
> any bug fixes that get checked in to production needs to be merged to
> trunk

How will the machine resolve conflicts?



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Subversion versus CVS

[Kaz Kylheku]

On Mon, 30 Dec 2002, Kyle Adams wrote:

> via patches and third-party add-ons (a la MetaCVS, which looks sweet by
> the way - just wish there was something like that for Windows, along
> with a GUI for it).

>From the home page you can download a binary distribution that runs
on Windows under Cygwin. Just unpack it relative to your / directory and it's
installed.   Be sure you to have Cygwin's CVS package installed too.

You're right about the second part: no GUI yet.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Subversion versus CVS

[Kaz Kylheku]

On Mon, 30 Dec 2002, Fischer, Oliver wrote:

> Hello,
> 
> a small question: Are they any plan to extend CVS in such a way, 
> that it offers similar features as subversion [1]?

Meta-CVS is a relatively tiny piece of software built on the CVS
platform. See signature.

You could say that it offers similar features to Subversion, but that
would be inaccurate. The big difference is that Meta-CVS works. I'm
confident that it can be deployed for production use.  The latest
release is 0.99; I'll be releasing 1.0 in a couple of days.

There are features broken in Subversion that worked right even
in very early releases of Meta-CVS.  For example, renaming of files is
done right. In Subversion, there is issue 898:

http://subversion.tigris.org/issues/show_bug.cgi?id=898

Incidentally, there is no bug database for Meta-CVS, because I haven't
received a single bug report yet. Which is good, because I have no
place to host it anyway.

One fellow had a serious installation problem, so I remotely logged in
to his machine to sort that out; it was just from using a bleeding edge
GCC version to compile the CLISP runtime. I found a more stable GCC on
his machine, pointed the configuration to that, and all built well.

Meta-CVS can store symbolic links. Back in August, I read that it was a
planned feature for Subversion, so I refactored it into Meta-CVS in one
weekend. I think it's still a planned feature for Subversion.

I don't think Subversion has a third-party importing feature that can
figure out renames and moves between snapshots. Meta-CVS does; and
it handles symlink reconfigurations as well.

Meta-CVS handles repeated merges from the same source. Like symlinks,
this feature is supposedly planned for post 1.0 Subversion.
 
-- 
Meta-CVS: directory structure versioning; versioned symbolic links;
versioned execute permission; versioned property lists; easy branching
and merging and third party code tracking; all implemented over the
standard CVS command line client -- http://freshmeat.net/projects/mcvs



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: update not getting empty directories

[Kaz Kylheku]

On Mon, 23 Dec 2002, Steve Salazar wrote:

> Subject: update not getting empty directories

Countersubject: user not reading --help update



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: (newbie) Which is the actual cvsroot?/remote repository access

[Kaz Kylheku]

On Thu, 19 Dec 2002, Mazza, Glen R., ,CPMS wrote:

> 1.) Using Linux (Redhat 8.0) I set up a cvs repository at
> /usr/local/cvsroot.  That created a subdirectory named CVSROOT underneath
> it.  Now, whenever a command requests "the path to CVS root" (e.g., in
> setting up xinetd pserver service, checkout/update commands, etc.)--I'm
> confused which directory CVS considers as the root:  /usr/local/cvsroot or
> /usr/local/cvsroot/CVSROOT?

CVSROOT is actually a directory that contains repository configuration.
It can be checked out as a module; changes committed to the files
belonging to this module bring about dynamic configuration changes in
the repository.

It should have been named CVSCONFIG or something else; giving it the
same name as that of the CVSROOT environment variable was a crass
stupidity that only causes confusion.

> 2.) Also, in trying to access a Linux CVS server from Windows NT, do I need
> WinCVS or another CVS client on my NT machine if using pserver
> authentication? 

You cannot use a CVS repository without CVS software.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Security options

[Kaz Kylheku]

On Thu, 19 Dec 2002, Phil R Lawrence wrote:

> My best idea is to leave cvs-phil with a regular shell, but disallow 
> su'ing to cvs-phil (via chuser on AIX, but how about linux?).  Since our 
> server will be physically secured, no one could directly log onto the 
> console as cvs-phil.  Then SSH will be configured to only allow the cvs 
> command.
> 
> Any other thoughts?

You can write a shell script which serves as the user's login shell.
That script can do arbitrary filtering to allow or disallow commands.
I had one such a script that would allow CVS access, but only to a
specified repository. It filtered out any -d option, and put in its
own.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: using cvs2cl xml output to extend cvs functionality

[Kaz Kylheku]

"Matthew Herrmann" <[EMAIL PROTECTED]> wrote in message 
news:<[EMAIL PROTECTED]>...
> hi everyone,
> 
> just thought i'd let people know, i'm doing some work on a definitive
> solution to the whole "cvs doesn't handle rolling back commits easily", "cvs
> can't tag files with the same log message", etc. problem.
> 
> here's the idea:
> 
> step 1) cvs2cl --xml generates XML output
> step 2) XSLT stylesheet converts changelog to cvs scripts for performing
> basic operations, like cvs up -jr1 -jr2.

Another idea:

  step 1) cvs2cl --lisp generates Lisp output
  step 2) Lisp program has field day with it

Of course, that requires:

  step 0) http://users.footprints.net/~kaz/cvs2cl-lisp.diff

;)
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Determining status

[Kaz Kylheku]

On Fri, 13 Dec 2002, Volpe, Christopher R (Research) wrote:

> I've noticed that "cvs status" is able to determine if a file is up to date or 
>locally modified very
> quickly, i.e., in much less time than would be required to extract the file from the 
>repository and
> do a comparison. How is this done? Is there some checksum stored away somewhere that 
>is used for the
> comparison? 

Look in CVS/Entries



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: open source bitkeeper

[Kaz Kylheku]

On Mon, 9 Dec 2002, jennyw wrote:
> On Mon, Dec 09, 2002 at 10:17:39AM -, mehul  choube wrote:
> > what is propritory bitkeeper?
> > 
> He meant proprietary. BitKeeper is a distributed CM tool from BitMover.
> Check out their Web site for more info: www.bitkeeper.com.  It's free

Next time think twice before performing the task of a search engine
for someone who is too stupid to use one.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Oops message from cvs process

[Kaz Kylheku]

Satya Prasad DV <[EMAIL PROTECTED]> wrote in message 
news:<[EMAIL PROTECTED]>...
> hi,
>We are using the RHL 7.1 with cvs software version cvs-1.11.1p1 patched 
> to get additional info for logging using AlternateInfo=yes in config. We 
> had no trouble with this s/w for over one year. Recently we upgraded the 
> server by increasing RAM to 512M and adding scsi drive for the cvs 
> repository partition.

That recent upgrade is possibly a big clue by four here!

> After this, the server started spewing out lots of Oops messages after 7-8 
> days of operation. If I reboot the machine the problem disappears for a 
> while and starts again.The oops seems to be result of the cvs process. Iam 
> listing the ksymoops output below.

No, oops messages are not the fault of the process; they are a kernel
or hardware problem. You should take this to a Linux kernel newsgroup.
There is no defect in CVS that can cause a kernel panic.

You alerady noted that this started happening after a hardware
upgrade. There is nothing in CVS like ``if (recent_hardware_upgrade())
crash_kernel();''.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs