Suppose a project has to branches: the head is the current,
development, release, and there is a stable branch, as well.
Suppose I'm about to make a change which is supposed to go in both the
head and the stable branch.
What would be the easiest way to achieve this? Is there an idiomatic
way
Hi,
Is it possible to verify partition type
fox fixing NTFS file modification time ?
After changing standart/daylight saving
time CVS report all files as modified.
P.S The same story with FAT 1 second
difference due to 16bit timestamp in modified time ??
=
Andrew G.
The way to do "locking" without breaking the CVS philosophy is through "cvs
watch" and "cvs edit" (specially when using the "cvs edit -c" and "cvs ci -c"
patches). To see who is "locking" files, use "cvs editors".
This topic has been discussed numerous times and I still haven't seen an
absolute
On Wed, Oct 18, 2000 at 05:59:06PM -0700, richard offer wrote:
I'm trying to generate a large patch that includes new files
[...]
But for the new files it starts creating files called /tmp/cvsx instead of
the files in the directory ?
ie looking at the diff.
Index:
A bunch of the hackers at my company are agitating for some better
tools for managing the process of merging groups of changes from one
branch to another. I've seen references on this list to scripts
(shell, perl, or something) to aid (I don't want to say automate) the
process of merging, when
This topic has been discussed numerous times and I still haven't seen an
absolute need to use "cvs admin -l".
Well, some people don't trust that if someone gets a conflict when
trying to merge, that the resulting file will be OK, because of human
errors.
Locking stalls development, but
Richard June wrote:
Correct me if I'm wrong, but cvs -T /tmp update should store all the
temporary files in /tmp as opposed to `pwd` correct? I'm using cvs v1.10.6
and the behaviour isn't like that, it is putting temp files in the
current. if this is proper behaviour what variable should I
No, if I do a cvs update it downloads the file to the current directory as
.file it has nothing to do with a conflict. I'm running out of space
onthe device and I need them to d/l to /tmp instead
On Mon, 30 Oct 2000, Derek R. Price wrote:
Richard June wrote:
Correct me if I'm wrong, but
Thomas Olausson wrote:
This topic has been discussed numerous times and I still haven't seen an
absolute need to use "cvs admin -l".
Well, some people don't trust that if someone gets a conflict when
trying to merge, that the resulting file will be OK, because of human
errors.
I
this way seems like second guessing your programmers too much. By the
same
token someone could accidentally write a bug into a program even while
normally
changing it, but can you really account for it using the tool? Probably
not...code reviews should be set up to prevent bad code from getting
1.5MB or so. that's perfectly fine if it's intentional, I just need it to
behave differently.
On Mon, 30 Oct 2000, Derek R. Price wrote:
Then that's probably an atomic file update trick. The temp file is created, written
to, and closed, then moved over the old file name. That this happens
On Sun, Oct 29, 2000 at 09:00 +0100, Gerhard Sittig wrote:
There's a file /usr/src/contrib/cvs/FREEBSD-upgrade (if only I
had the bookmark around with the web frontend to the FreeBSD
source repo -- I can provide it on Tuesday) with the most
important section for you at its end:
On Mon, Oct 30, 2000 at 02:58:42PM -0500, Richard June wrote:
1.5MB or so. that's perfectly fine if it's intentional, I just need it to
behave differently.
Delete the file that's being updated, then do an update.
mrc
--
Mike Castle Life is like a clock: You can work constantly
Not an option, this is scripted, only have a little bit of free space, and
I need cvs to not write scratch files into the working directory.
It doesn't improve anything that For the most part I'm dealing with binary
files.
On Mon, 30 Oct 2000, Mike Castle wrote:
On Mon, Oct 30, 2000 at
* $ from [EMAIL PROTECTED] at "30-Oct: 9:56am" | sed "1,$s/^/* /"
*
*
* On Wed, Oct 18, 2000 at 05:59:06PM -0700, richard offer wrote:
* I'm trying to generate a large patch that includes new files
* [...]
* But for the new files it starts creating files called /tmp/cvsx instead
of
* the
The following message is a courtesy copy of an article
that has been posted to gnu.cvs.help as well.
"Fred W." [EMAIL PROTECTED] writes:
Prior to making changes I want to tag the current version as 'REL_1_0 '
. Assume I only have one file 'test.txt'. When I look at the log it
shows the tag
Hi,
I have a CVS user who continues to checkout modules or update files from
the wrong branches. Can I restrict her ability to update from
particular branches or main trunk? The only thing I can find about
access rights with CVS is to do with Unix file permission this is
fine if you want
On Mon, Oct 30, 2000 at 04:24:46PM -0500, Richard June wrote:
Not an option, this is scripted, only have a little bit of free space, and
I need cvs to not write scratch files into the working directory.
It doesn't improve anything that For the most part I'm dealing with binary
files.
Well,
Here's the deal, I have limited space(1.5MB free on a 14MB partition,
filenames that change, so stuff gets deleted and added as opposed to just
patched, not that it would matter anyway, most of the files are binary. I
don't care about the transient state, only that the final file is intact.
All I
19 matches
Mail list logo
