--- Kaz Kylheku <[EMAIL PROTECTED]> wrote:
> I've noticed that if you execute a cvs unedit, and
> choose to revert
> the changes, it reverts the timestamp as well! The
> behavior should
> be like the new -C option of update.
IMHO, "cvs unedit" should not be reverting the file at
all since:
1. The
--- Anne McCaffrey <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I am facing problems with Attic directories.
> I have a script that disallows users from removing
> files using cvs remove.
> To implement additional security, I have made all
> Attic directories in the repository read only, since
> all
--- Anne McCaffrey <[EMAIL PROTECTED]> wrote:
> No,the files are not added to branch.
> The 'Branch' is MAIN and the CVS tags shows HEAD.
I don't know why "cvs add" would be doing this, then.
Also, how do you prevent users from going into the
repository and removing an archive file that's /not/
--- Anne McCaffrey <[EMAIL PROTECTED]> wrote:
> I have not invited any 'thoughts' or 'opinions' on
> how
> I am using cvs.If you can't answer my question, pls
> don't reply;we can go on arguing about the pros and
> cons of someone's practices.I don't see any point in
> it.
If you want to be so de
--- "Johnson, Susan" <[EMAIL PROTECTED]> wrote:
> I'm used to ClearCase, where a person worked within
> a
> dynamic view and you could build, label (tag),
> branch,
> merge and do everything within the same workspace.
>
> How does CVS differ from that model?
This is pretty much how I use CVS.
On
--- "Schoep, Grant @ STORM" <[EMAIL PROTECTED]>
wrote:
> Is it possible to have CVS perform some type of
> action on types of files
> before checking it in? I'd like to configure our
> server for all java and C++
> code to do some nicetys, like strip out ^M's and
> replace bloody tabs with
> spaces
--- "Zieg, Mark" <[EMAIL PROTECTED]> wrote:
> I don't deny that it is worth challenging the
> requirements, if it seems a
> battle which can be won -- but there are also cases
> where developers must
> cede defeat, and simply come up with a "best fit"
> solution that meets the
> customer's request.
--- Brandon Brinkley <[EMAIL PROTECTED]> wrote:
> I've worked on an Oracle Financials customization
> project that sounds very
> similar. No single developer owned the database,
> but there were also two
> additional databases for integration testing and
> QA/UAT. The private
> project approach w
--- Kris Thielemans <[EMAIL PROTECTED]>
wrote:
> > By default, diff compares against the version you
> checked out. If you
> > want to compare against the top of the tree, you
> have to specify -r
> > HEAD.
> >
>
> Hi,
> this has given me some problems before. I think it
> would be helpful for a
--- "LIU,SHI-ZHOU (HP-China,ex2)" <[EMAIL PROTECTED]>
wrote:
> CVS server version:1.11.2 on HP-UX 11i
> CVS client: Win CVS 1.3.8.1 on Win2K
I'd upgrade the client to be able to take advantage of
some newer commands (eg "cvs edit").
> How to set CVS be the reserved checkout mode only?
> I mean t
--- Alejandro_Gómez <[EMAIL PROTECTED]> wrote:
> Ppl, I need to set strict locking on my
> repository...
Why? Are you able to use the advisory locks patch
available at SourceForge under project RCVS?
Noel
__
Do you Yahoo!?
Y! Web Hosting - Let the
--- Andreas Otte <[EMAIL PROTECTED]> wrote:
> Thank you all for your input on the topic of shared
> resources. Made me think about it, but unfortunally
> it is something I can not change in this database
> project. However, cvs can be made to ignore the
> content of the Root-Files with an entry in
I've been waiting for someone to point out that files
in the repo have a ,v suffix, but since noone has,
I'll do it ;-)
The command would be: find $CVSROOT -name foo.c,v
Anyway, that's beside the point. Directly accessing
the repo is bad etiquette :-)
I'm wondering if "cvs -n co" would act like
--- Larry Jones <[EMAIL PROTECTED]> wrote:
> Noel Yap writes:
> >
> > Oh well, there goes that idea. Does anyone know
> if
> > there's any reason why this shouldn't give the
> same
> > output as "cvs co"?
>
> The pragmatic reason
There're several things (with varying pro's and con's)
you can do:
1. move back the repo until you've checked in
everything you need (and don't checkout another
working directory until it's moved back)
2. create a symlink (or mount the new repo) to the
location of the old repo
3. modify all your CV
--- Neil Dombrowski <[EMAIL PROTECTED]> wrote:
> I have to allow some clients access to our company's
> cvs repository via
> ssh, but I don't want to give them a prompt, only
> access to cvs
> commands. How might I accomplish this?
The subject of your email implies you have an inkling.
There's a
--- "Riechers, Matthew W"
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
> > A. checkout new working dir using new repository
> location
> > B. transfer content of old working copy to new
> working copy
> > C. delete and cvs remove files from new working
> copy if necessary
> >
--- "Kaj E. Ozolins" <[EMAIL PROTECTED]> wrote:
> we swiched from VSS to CVS (mixed CVS and WinCVS)
> recently. Though all
> developers love to use CVS rather than VSS some are
> missing the ability
> to make particular reserved checkouts. (Okay... I
> know about the
> philosophical dimension this
--- Phil R Lawrence <[EMAIL PROTECTED]> wrote:
> OK, I've settled on either importing our entire ERP
> source with -kb or
> writing a script to traverse the sourcetree and
> check in the files
> intelligently as either binary or text. (anyone
> already have a script
> that does this?)
>
> Now,
--- "CHARLES HART, BLOOMBERG/ 499 PARK"
<[EMAIL PROTECTED]> wrote:
> um, I'm a newbie at CVS, so I've read more of the
> documentation than anything
> else, but the answers I've seen so far for the
> security question seem to have
> missed one vital point. People have write access to
> spots in th
One other problem with pserver is that passwords are
stored "in the clear" on the users' home directories.
At least with SSH, the keys can be encrypted using a
password that the user enters either upon login or on
a per-use basis.
Noel
--- Steven Tryon <[EMAIL PROTECTED]> wrote:
> We run pserver
--- Paul Sander <[EMAIL PROTECTED]> wrote:
> A chroot environment is only good at containing
> what's inside it. It
> does not prevent access to the chroot environment
> from outside.
I see. I guess it's obvious that the repository would
have to be within the chroot'ed environment meaning
that s
--- "Zieg, Mark" <[EMAIL PROTECTED]> wrote:
> > One other problem with pserver is that passwords
> are
> > stored "in the clear" on the users' home
> directories.
> >
> > At least with SSH, the keys can be encrypted using
> a
> > password that the user enters either upon login or
> on
> > a per-us
--- "Zieg, Mark" <[EMAIL PROTECTED]> wrote:
> > Password-protected keys help protect them against
> > theft. I would encourage everyone to use such
> keys.
> > Or did I misunderstand your post?
>
> Are you talking about ssh-agent, or passphrase-based
> ssh keys, or an
> external layer of encrypt
--- Eric Vaughan <[EMAIL PROTECTED]> wrote:
> Noel,
>
> While surfing the web for information about a
> project I am working on, I came
> across a message list that included a conversation
> back in May 2002 which sort
> of corresponds to what I am trying to do. I know you
> also mentioned a scr
--- Mike Ayers <[EMAIL PROTECTED]> wrote:
>
> Here's a bit of a challenge for the list. We need
> to set up a CVS
> repository on a Linux server such that the users
> can't modify the
> files, except through proper CVS operations. The
> catch? They are
> currently permitted to log into
--- Mariappan Muthiah <[EMAIL PROTECTED]> wrote:
>
> > Hi Noel
> >
> > I have CVS server running on Redhat Linux 7.3. I
> got this patch enh-multiple_edits+reservations.diff
> for reserved checkouts. Can you explain me how to
> apply this patch into CVS?
If you're on Unix, just apply patch (man
Set LockDir in CVSROOT/config.
Noel
--- Janning Vygen <[EMAIL PROTECTED]> wrote:
> hi,
>
> i am quite new to cvs and my question might be based
> on a
> misunderstandig of important concepts.
>
> i have a repository in /home/cvsroot
> serveral projects are imported like
> /home/cvsroot/project
set LockDir in CVSROOT/config
--- Janning Vygen <[EMAIL PROTECTED]> wrote:
> hi,
>
> i am quite new to cvs and my question might be based
> on a
> misunderstandig of important concepts.
>
> i have a repository in /home/cvsroot
> serveral projects are imported like
> /home/cvsroot/project1
>
>
I think the easiest way to do this (although I may be
biased) is to install one or some of the patches
available at SourceForge under project RCVS. The
patches I'm thinking of will add checking to edit and
commit. Developers will need to modify their .cvsrc
files to default to the right command
ours truly if
> they're gonna be done at
> all.. (I need a rather authorative/authoritarian
> setup for just about
> everything here).
>
> In a week or so, they'll be happy having a CVS.. ;)
>
> Thx so far!
>
> Ronald
>
> > -Original Message-
He could patch the client so that it passes the
"right" options (eg "cvs edit -c" and "cvs ci -c") in
by default.
Noel
--- Martin Ellison <[EMAIL PROTECTED]> wrote:
> > I'm hoping to find a server-side only config,
> because the induhvidual
> > settings would have to be done by yours truly if
> t
I think a better "repository commands" interface needs
to be designed (ie the "r" prefix is lacking).
Anyway, in the meantime, what we do to do what you ask
is to keep a central checked out copy for use by the
cron'ed editors command that's part of our development
web page.
Hope this helps,
Noel
Use SSH instead of pserver.
Noel
--- Mark <[EMAIL PROTECTED]> wrote:
>
> What's the best way to disable the update.prog and
> checkin.prog functionality?
> Currently I have commented out 2 REQ lines in the
> source that seem to call
> this functionality. Is this the best way to do this?
>
> We
Can't you just "cvs add " to add everything
recursively?
As for deletion, I'm sure you can work with the output
of "cvs -n up" to get a list of files that've been
removed from your working area (but what happens if
some of these files were actually added by someone
else?)
Noel
--- David D <[EMAI
--- Paul Sander <[EMAIL PROTECTED]> wrote:
> >--- Forwarded mail from [EMAIL PROTECTED]
>
> >My company is currently using CVS to manage some
> third-party vendor
> >really big, big tree with really many, many very
> big, big files.
>
> >The result, obviously, is totally unacceptable.
> Even o
It sounds like you need to reorganize your code. A,
B, and C shouldn't exist within a common module, src.
Instead, they should exist within separate modules
(you may be able to use module aliases, but I think
they cause more confusion than they alleviate).
Hope this helps,
Noel
--- Xavier Mari
Use file system permissioning and LockDir in
CVSROOT/config.
Noel
--- Hafeez Mohammad <[EMAIL PROTECTED]> wrote:
> Is there a way for not allowing a user to commit in
> the repository.
>
> cvs watch just watches the files but does not have a
> cpability to Stop the user from commiting the
> ch
I think there may be atomicity problems when mounting
a CVS repository via NFS.
I'm assuming you're asking about POSIX file system
ACLs.
It's perfectly fine to use ACLs within the CVS repo,
in fact I promote them since it makes things much
simpler. However, be sure you understand exactly how
pe
--- Axelle <[EMAIL PROTECTED]> wrote:
>> > I think there may be atomicity problems when
>> mounting
>> > a CVS repository via NFS.
>>
>> Well, there might be individual synchronization
>> problems, but mainly,
>> I do not have any problem using it myself.
Such problems would occur rarely in prac
It's a piece of cake to install CVS server on Unix. I
haven't had experience doing so on NT (you'll probably
need the Cygwin port).
In addition to getting past initial problems, a
consultant would also get you up and running with the
CVS way of doing things (in my experience, each
version contro
--- Pierre Asselin <[EMAIL PROTECTED]> wrote:
> "vincent_choplin" <[EMAIL PROTECTED]> writes:
> >would we have to stop working while we put CVS up
> or can one of us do
> >it while the others go on with the developpement?
>
> Nah, don't stop. When CVS is ready, import what you
> have and save
>
The latest patch on RCVS should have this working (I
haven't tested it myself, yet).
What exactly are you looking for?
Noel
--- "MW Mike Weiner (5028)" <[EMAIL PROTECTED]> wrote:
> Dear list readers -
>
> I noticed some interesting patches for cvs for
> increased functionality for
> inclusion
The only way I can think of doing this is:
1. Create a cvs-server wrapper that checks permissions
to import.
2. Use SSH to allow execution of that wrapper only
upon login.
3. Create separate logins to be used for this purpose.
4. Don't allow execution of the original cvs-server
through any other m
rfect. If not, why not?
Noel
--- "MW Mike Weiner (5028)" <[EMAIL PROTECTED]> wrote:
> I am working with locking and the ability to use cvs
> edit -c to lock
> files
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On B
mechanism that was inherent in MS Visual Source
> Safe, so we can have
> multiple developers editing the same file in
> separate (or even the same)
> sandboxes. The next step is which patches do i need
> from the rcvs project to
> use with the current cvs-1.11 install??
>
> Than
I had thought that "cvs watch on dir" was working at
one point.
Anyway, I think "cvs watch on dir" should work as
doc'ed since this would make it work like all the
other commands (ie recursively).
Noel
--- Larry Jones <[EMAIL PROTECTED]> wrote:
> Colm Murphy writes:
> >
> > The manual says that
Why does it need to work for both pserver /and/ SSH?
Having SSH working should circumvent almost any need
for pserver.
Noel
--- Wolfgang Kormann <[EMAIL PROTECTED]>
wrote:
> hello,
> how can I build a security concept for CVS on SuSe
> Linux...
>- I'd like define groups
>- and it should
--- Larry Jones <[EMAIL PROTECTED]> wrote:
> Noel Yap writes:
> >
> > Anyway, I think "cvs watch on dir" should work as
> > doc'ed since this would make it work like all the
> > other commands (ie recursively).
>
> It does work recursively,
You tried forcing serial development into a tool meant
for concurrent development :-)
Seriously, though, I (and I think most others) see
that there is absolutely no reason to _prevent_
concurrent development although I think it should
sometimes be /avoided/.
The way to avoid it is through commun
If you want security (as the subject of your email
suggests), use SSH instead of pserver. pserver has
many insecurities.
Noel
--- [EMAIL PROTECTED] wrote:
> Hello,
>
> I'm using cvs with mandrake 8.1
> I wonder if pserver is the best way to proceed, but
> it seems to be easier
> to implement.
Greg has responded with most of what I wanted to say.
I do have something to add, though. If your intent is
to have students be able to grant access to other
students, SSH is sufficient and is way more secure
than any other method out there. However, if you want
students to be able to grant acc
If you're using SSH or rsh:
1. set LockDir in CVSROOT/config
2. manage the CVSROOT permissions using file system
ACLs (hopefully you'll have these)
Noel
--- anamika mathur <[EMAIL PROTECTED]>
wrote:
> Dear Friends,
> Is it possible to restrict checking
> out of CVSROOT directory t
- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> [ On Thursday, January 31, 2002 at 12:47:22 (-0800),
> Noel Yap wrote: ]
> > Subject: Re: Creating Per-User repositories
> >
> > I do have something to add, though. If your
> intent is
> > to have students b
Initially:
find $CVSROOT -type d | xargs chmod g+s
I forget whether SGID is inherited by new
subdirectories. If not, have a loginfo script set it.
Noel
--- GOMEZ Henri <[EMAIL PROTECTED]> wrote:
> >> The problem is that each time a cvs user like bob
> commit
> >> a file or directory, like test
Have you tried the patches available at
SourceForge/RCVS?
If so, your development process should include the
following:
1. Developers put "edit -c" in ~/.cvsrc.
2. Developers "cvs edit" file(s).
3. If the edit aborts (due to other editors),
developer communicates with others.
4. Developers procee
Initially, directories within the repo don't have SGID
set. You'll have to do this manually.
Noel
--- GOMEZ Henri <[EMAIL PROTECTED]> wrote:
> >Initially:
> >find $CVSROOT -type d | xargs chmod g+s
> >
> >I forget whether SGID is inherited by new
> >subdirectories. If not, have a loginfo script
No, there's no reason to reset SGID on all the
repository directories. You would only need to set it
for the newly created subdirectory with something
like:
chmod g+s new-subdir
Read more about loginfo scripts to see how you can
write such a script.
Noel
--- GOMEZ Henri <[EMAIL PROTECTED]> wrot
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> I think you're dreaming about problems which should
> not exist. I
> believe it was implied in the original post that all
> authorised students
> would implicitly be given permission to access the
> CVS server. If one
> uses SSH this this means th
None that I know of. In fact, I had thought about
creating such a patch, but rethought it as removing
some controls from concurrent development along
branches (although, granted, you don't get full
control over such development with the current edit
feature).
Noel
--- Stuart Donaldson <[EMAIL PR
Your abject ignorance is pardoned :-)
uuencoding and uudecoding won't help anything since
CVS diffs and merges on a line-by-line basis. Doing
this with a uuencoded file will likely give you
garbage. IOW, the diff/merge problem has nothing to
do with a file's textness.
Noel
--- "EXT-Corcoran, D
Any user that needs read access to the repository will
need to be able to create a lock file. This means
that read-only users need write permissions on the
directory where that lock file is created. However,
if write permissions were granted to the repository,
users would also gain checkin prive
Yes, if they don't use "cvs edit -c", they'll still be
able to do concurrent development.
Usually, I'll have "edit -c" in my ~/.cvsrc file then
use "cvs edit -f" if I need to do concurrent
development. I feel it gives me more control (or at
least more info) that way.
Please let me know how it g
Not that I know of. In fact, every now and then,
there's talk of removing "cvs admin". Why would you
ever want to do such a thing?
Noel
--- X X <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I want to change the behavior of CVS when locking
> and editing files. I want
> the lock to lock the file and
e. It does seem crazy if you are used to
> working with CVS, but for my
> team it makes sense.
>
> Thanks.
>
> >From: Noel Yap <[EMAIL PROTECTED]>
> >To: X X <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> >Subject: Re: Changing CVS 'Lock' and 'Ed
Concurrent access to the working directory is no safer
than concurrent access to a file. The clients will
not synch.
Noel
--- Stephan Feder <[EMAIL PROTECTED]> wrote:
> Sorry, perhaps I did not state my question correctly
> so maybe the
> following example clarifies what I want to know:
>
> Sup
--- Paul Sander <[EMAIL PROTECTED]> wrote:
> The economically rational thing to do is to push the
> detection of bugs
> earlier into the process (where they're cheaper to
> fix), provide
> support that's good enough to yield repeat business,
> and have the support
> center feed back efficiently in
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> Without knowing details of either sitution I think
> you have vastly
> mis-interpreted the meaning of the word "simple".
> Something that seemed
> "simple" to you obviously turned out to be
> exceedingly complex for CVS.
> You either chose the wron
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> [ On Tuesday, February 19, 2002 at 18:04:06 (-0500),
> Eric Siegerman wrote: ]
> > Geez, that's just what Paul's been saying all
> along! It's
> > everyone else that's been treating his defence of
> ClearCase as
> > rank heresy.
>
> Yeah, so why d
--- Eric Siegerman <[EMAIL PROTECTED]> wrote:
> Geez, that's just what Paul's been saying all along!
> It's
> everyone else that's been treating his defence of
> ClearCase as
> rank heresy.
I agree. I wonder how many of these heresy-sayers
have actually actively used ClearCase.
Noel
_
--- Paul Sander <[EMAIL PROTECTED]> wrote:
> Even on my personal system where my toy projects
> make very few demands on
> CVS (no branching other than vendor branches, no
> concurrent development,
> no binary files, no reorganizations, no use of *info
> files, small source
> files, few source fil
--- Paul Sander <[EMAIL PROTECTED]> wrote:
> We were using CVS in the way that it was designed,
> but the robustness
> of the implementation gave us more grief than I care
> to remember. My
> argument has become somewhat weaker now because CVS'
> quality of
> implementation has improved substanti
--- Santosh Cheler <[EMAIL PROTECTED]> wrote:
>
> - Original Message -
> From: "anamika mathur"
> <[EMAIL PROTECTED]>
> > Dear Friends,
> >
> > Is it possible to have read/write
> access
> > to specific files and directories in the
> repository
> > using CVS for various us
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> [ On Wednesday, February 20, 2002 at 07:45:24
> (-0800), Noel Yap wrote: ]
> > Subject: Re: Converting ClearCase to CVS
> >
> > One of the most current arenas where CVS is not an
> > ideal tool is
--- "Mark A. Flacy" <[EMAIL PROTECTED]> wrote:
> In Java, a refactoring into a different package
> practically forces a move
> into another directory. That's a real PITA with
> CVS; while that may be my
> problem rather than CVS's, it would entice me to
> find a tool that makes it
> less of a pro
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> [ On Wednesday, February 20, 2002 at 13:19:22
> (-0800), Noel Yap wrote: ]
> > Subject: Re: refactoring when using CVS
> >
> > The difference is that as a language, C doesn't
> demand
> >
--- "Thornley, David" <[EMAIL PROTECTED]> wrote:
> > From: Noel Yap [mailto:[EMAIL PROTECTED]]
> > There you have it, yet another space where CVS
> isn't
> > ideal: XP.
> >
> No, XP in Java. The original XP people used
> Smalltalk,
> a dy
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> [ On Thursday, February 21, 2002 at 19:15:45
> (+0530), Jasmeet Singh Virdi wrote: ]
> > ne pointer on how to impliment LOCKS in CVS for
> NT server on a win2K
> > box, with only windows clients.
>
> First of all you probably cannot do what yo
--- Paul Sander <[EMAIL PROTECTED]> wrote:
> >--- Forwarded mail from [EMAIL PROTECTED]
> >If you have all of your source in one big pile, you
> can do a "javac *.java"
> >and things should sort themselves out.
>
> Unfortunately, if this is what your build procedure
> consists of, then
> you lose
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> So Java is worse than C. We knew that already. It
> takes more man-hours
> to write, results in more lines of code, runs on
> fewer platforms,
> generally runs a lot slower, sometimes even slower
> than the equivalent
> perl code, isn't as secure
--- "Thornley, David" <[EMAIL PROTECTED]> wrote:
> > From: Noel Yap [mailto:[EMAIL PROTECTED]]
>
> > AFAIK, XP promotes "Refactor early, refactor
> often."
> > If so, and given Greg's premise that
> refactorisation
> > should be ra
--- "Thornley, David" <[EMAIL PROTECTED]> wrote:
> > From: Noel Yap [mailto:[EMAIL PROTECTED]]
>
> > Other than theoretical attacks found by
> acadamecians
> > (that I think were later fixed) and possibly holes
> > within Visual J++, I haven't h
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> [ On Thursday, February 21, 2002 at 12:59:06
> (-0800), Noel Yap wrote: ]
> > AFAIK, XP promotes "Refactor early, refactor
> often."
> > If so, and given Greg's premise that
> refactoris
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> [ On Thursday, February 21, 2002 at 16:13:57
> (-0600), Thornley, David wrote: ]
> > Subject: RE: refactoring when using CVS
> >
> > So, just remember that it will often be futile to
> ask
> > for credible sites showing insecurities, unless
> you ar
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> CVS is not and has never been very useful for
> initial development under
> any methodology that doesn't involve sharing of the
> code under
> development (and sharing in a non-XP manner!).
I disagree.
> Sure
> there are pedants
> amongst the CVS
--- Kaz Kylheku <[EMAIL PROTECTED]> wrote:
> That's terrible! What if the resulting command line
> violates the
> systems's environment passing limit? Of course, you
> want:
>
> find . -name '*.java' -print | xargs javac
>
> hopefully, none of the names contain spaces and
> newlines, but
--- Tom Plunket <[EMAIL PROTECTED]> wrote:
> Then again, I'm not renaming files like crazy-
> there's no reason
> to as far as I can tell. The classes (C++
> development) don't
> need to change name, most of my "refactoring" work
> ends up
> splitting out functionality and creating new files.
>
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> Of course Aegis is even better with XP than CVS
> because of the two-phase
> commit which helps with the "Only one pair
> integrates code at a time"
> rule; and also with the ability to enforce and run
> test modules for
> every commit (which obviou
--- Mark <[EMAIL PROTECTED]> wrote:
> - if someone is working on file A on branch 1 and
> someone else refactors file A
> on branch 2, what good is a merge, using CC or CVS?
> Wouldn't the person doing
> the merge have to collect/identify the changes on
> branch 1 and then figure out
> where they
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> Where it becomes bad is when it adversely impacts
> other members of a
> multi-person project. CVS provides ways to isolate
> such practices
> though so that they don't adversely impact the
> project (per developer
> branches).
Since bare-bones CV
--- Kaz Kylheku <[EMAIL PROTECTED]> wrote:
> In article
> <[EMAIL PROTECTED]>, Noel Yap
> wrote:
> >--- Kaz Kylheku <[EMAIL PROTECTED]> wrote:
> >>find . -name '*.java' -print0 | xargs -0 javac
> >
> >Keep in mind that sinc
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> No, you're full of crap too if you think that's a
> necessary feature.
If it's not necessary, then it's at least very nice to
have.
> First off tell me how often you've actually had to
> do this operation in
> relation to other operations.
Quite
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> [ On Friday, February 22, 2002 at 10:28:16 (+0100),
> Peter Ring wrote: ]
> > Subject: RE: ANN: cvssh - secure ext-to-pserver
> bridge
> >
> > We need to control access on files that cannot
> (i.e., CANNOT) be logically
> > arranged into disjunct di
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> I don't need to use any such over-burdened fancy
> system. I'm extremely
> happy with the way things work now in CVS -- there's
> more than adequate
> support for tracking renames across history, at
> least form the point of
> view of anyone actual
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> [ On , February 22, 2002 at 11:09:21 (-0500), Arcin
> Bozkurt - Archie wrote: ]
> Of course a merge won't work across renames. Who
> cares? How often has
> this happened to you? The wording of your question
> suggests: NEVER.
Well, if I were us
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> [ On Friday, February 22, 2002 at 12:05:34 (-0800),
> Paul Sander wrote: ]
> How often have you had to run two or more commands
> to look at the
> history of a file across a rename? (which is what I
> asked in the first
> place)
Also, I'm curious
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> I'm almost willing to bet that unless things turn
> about face quickly
> then soon the countries hiding today's "terrorists"
> are going to start
> looking pretty attractive to freedom lovers (and
> fighters) everywhere!
And in this respect, capita
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> then you are, sadly, disillusioned, and perhaps that
> explains why you
> don't always grasp how to make effective use of CVS.
That's right Greg, start making more false statements.
> > SCM by definition is the identification of what
> goes
> > i
--- Kaz Kylheku <[EMAIL PROTECTED]> wrote:
> Before I published Meta-CVS 0.0, I had already
> renamed a bunch of
> files in its own source code.
Do you think Meta-CVS can be made part of CVS proper?
Noel
__
Do You Yahoo!?
Yahoo! Sports - Coverage
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> [ On Friday, February 22, 2002 at 08:09:28 (-0800),
> Noel Yap wrote: ]
> > I would argue that "All code must have unit tests"
> is
> > as practically unenforcible as "All commits must
> ha
1 - 100 of 307 matches
Mail list logo
