Python, licenses and CVS
Hans Nowak
I'm currently developing a program (in Python, obviously) and plan to
publish it. Before I do so, though, I would like to have some opinions
on the following:
- should I use a license / copyright notice?
- if so, which one would you recommend?
I know of the GPL, Python license, BSD license etc, and opensource.org
has a long list of them, but I absolutely hate legalese, and reading
all of this and pondering the possible consequences of picking one
over the other makes me cringe. Does someone have a pointer to a
page with some concise explanations of these licenses?
Then there's a second point: I see that many projects use version
control (usually CVS). I tried using DJGPP's cvs, but it
(unsurprisingly) doesn't work well on WinXP. There's such a thing
as WinCVS, but the whole process strikes me as clumsy... checking
in and out and committing every time something changes... what is
the point of this? What happens if you forget a step? Does it have
substantial benefits over versioning your files by hand, aside from
having a repository through which you can undo changes?
TIA,
--Hans
Tim Hammerquist
> Howdy y'all,
>
> I'm currently developing a program (in Python, obviously) and plan to
> publish it. Before I do so, though, I would like to have some opinions
> on the following:
>
> - should I use a license / copyright notice?
> - if so, which one would you recommend?
>
> I know of the GPL, Python license, BSD license etc, and opensource.org
> has a long list of them, but I absolutely hate legalese, and reading
> all of this and pondering the possible consequences of picking one
> over the other makes me cringe. Does someone have a pointer to a
> page with some concise explanations of these licenses?
The following page has a long list of licenses and their explanations.
The list seems somewhat biased towards the GPL, since it's hosted on
gnu.org, but is fair in its facts.
Python has had several licenses in recent times; this page mentions the
brief GPL-incompatible license and the current GPL-compatible one, so
you can make sure you get the right one.
http://www.gnu.org/licenses/license-list.html
In my case, my perl modules are released under the Artistic License
(like Perl) for consistency, while most other software I write comes
under the GPL or whichever GPL-compatible license is most appropriate.
HTH
Tim Hammerquist
--
The court finds everyone to be in contempt (including himself :-), and
orders everyone sentenced to five years hard labor. (Working on Perl,
of course.)
-- Larry Wall in <1998072115...@wall.org>
Brent Stroh
>There's such a thing
>as WinCVS, but the whole process strikes me as clumsy... checking
>in and out and committing every time something changes... what is
>the point of this?
As someone who has spent some time in software configuration management,
let me suggest that it might seem less clumsy if you rework your definition
of when to commit.
If you're in the middle of ongoing development, you don't need to commit
after every line of code. You only need to commit when you feel it's a
good idea to have a copy of a particular stage of development.
Once you release this code to testers, the universe, whatever, you'll want
to be sure you check in (and tag) each release level, to be sure you know
what folks will be asking questions about.
Bottom line: You only need to commit what you need to get back to.
On projects with multiple developers, that changes a bit, but I've found my
personal CVS repository for all of my tools and toys to be invaluable.
>What happens if you forget a step? Does it have
>substantial benefits over versioning your files by hand, aside from
>having a repository through which you can undo changes?
Letting the tool do versioning eliminates a lot of housekeeping and wasted
disk space. It also removes a potential source of human error. IMO.
Kragen Sitaker
> - should I use a license / copyright notice?
If you want people to use the code, yes; if they don't have a written
license, the code is still copyrighted by you (assuming you live in a
Berne Convention country) and they can still infringe your copyright.
They might have an 'implied license', consisting basically of what
you've encouraged them to do, but I feel a lot more comfortable with
an explicit license.
> - if so, which one would you recommend?
A popular one, because if you don't use a popular one, people who take
this stuff seriously and hate legalese won't even consider using your
software, because they'd have to read another license.
> I know of the GPL, Python license, BSD license etc, and opensource.org
> has a long list of them, but I absolutely hate legalese, and reading
> all of this and pondering the possible consequences of picking one
> over the other makes me cringe. Does someone have a pointer to a
> page with some concise explanations of these licenses?
The Free Software foundation has a page at
http://www.fsf.org/licenses/license-list.html that is more or less
what you want. My summary is as follows:
- GPL: you can use this software freely but can't incorporate it into
proprietary software without negotiating with the author for special
permission
- BSD: you can do whatever you want with this software. (There's an
older version of the BSD license which includes a clause that
requires credit be given; this is generally considered annoying.)
> Then there's a second point: I see that many projects use version
> control (usually CVS). I tried using DJGPP's cvs, but it
> (unsurprisingly) doesn't work well on WinXP. There's such a thing
> as WinCVS, but the whole process strikes me as clumsy... checking
> in and out and committing every time something changes... what is
> the point of this? What happens if you forget a step? Does it have
> substantial benefits over versioning your files by hand, aside from
> having a repository through which you can undo changes?
Cygwin cvs works well on pre-XP versions of NT. I haven't tried XP.
CVS doesn't require you to check out repeatedly, and you only check in
when there are changes.
Version control is a huge benefit when you're trying to work on
something with other people; it keeps you from accidentally destroying
their work. It's not as big a win with individual projects, but it
still has some advantages:
- I can type 'cvs annotate' to see when each line of code in my work
area was added --- what date, what time. (And by whom.)
- I can type 'cvs diff -D 2001-10-25' and see the changes since
October 25th.
- I can type 'cvs diff' and see what changes I haven't committed,
which often keeps me from committing typos in comments (where I typed
some character in the wrong window)
- saving my current work state is quicker than with a copy-tree, and
it takes less disk space, which makes it easier to back up my entire
work history.
That said, I still mostly use it when I'm working with somene else, or
when I have multiple copies of files on different machines that I
might edit independently. (I keep my PIM stuff --- calendar,
addresses --- this way.)
Werner Schiendl
...
There are some more things I really like about version control.
+ You need only backup your CVS repository and are relatively safe against
big data loss in case some part of the hardware decides to break down. (I
know that one should always have a good backup anyway, but I tend to be
realistic too). E. g. in our office we keep virtually everything in our
source control system (even documentation, specification files, etc.). When
my box is suddenly dead, the worst that is lost are my bookmarks, the rest
is backed up (at least the last working version) in source control.
+ I speeds up development a lot, at least for me. Before having source
control, I spent a lot of time to backup things before trying a new way to
do something. By now, you just get a fresh working copy of what you intend
to change, try your stuff as desired. If you find out that it's not worth
the change, you do not need to manually restore any changes (which offers
great opportunity to forget some 'minor' changes) but simple discard your
changes and let source control care for the rest.
That said, I use source control for virtually anything. One gets used to the
process very quickly, and when you come to the point where an automated
rollback does a good job, you'll safe more than you've invested (in terms of
time and hassles).
just my 0.02 ?
Werner
Hans Nowak
Thanks to everyone who replied to my questions about licenses
and CVS. Things are clearer now.
I have a follow-up question though. The project I'm currently working on
is well suited for third-party
contributions; it makes sense for others to add modules if
they want to. If my code is released under, say, the GPL, what
happens when someone else wants to contribute to it? Does the
new code have to be GPL too? Or GPL-compatible?
TIA,
--Hans
phil hunt
>Howdy y'all,
>
>I'm currently developing a program (in Python, obviously) and plan to
>publish it. Before I do so, though, I would like to have some opinions
>on the following:
>
>- should I use a license / copyright notice?
Yes
>- if so, which one would you recommend?
Depends on what you are trying to achieve.
>I know of the GPL, Python license, BSD license etc, and opensource.org
>has a long list of them, but I absolutely hate legalese, and reading
>all of this and pondering the possible consequences of picking one
>over the other makes me cringe. Does someone have a pointer to a
>page with some concise explanations of these licenses?
If you want a copyleft license, choose the GPL. If not, consider
the BSDL.
>Then there's a second point: I see that many projects use version
>control (usually CVS). I tried using DJGPP's cvs, but it
>(unsurprisingly) doesn't work well on WinXP. There's such a thing
>as WinCVS, but the whole process strikes me as clumsy... checking
>in and out and committing every time something changes... what is
>the point of this? What happens if you forget a step? Does it have
>substantial benefits over versioning your files by hand, aside from
>having a repository through which you can undo changes?
Depends. If only one person is working on the project, CVS is overkill.
If lots of people are working on it, it's a good idea.
--
*** Philip Hunt *** ph...@comuno.freeserve.co.uk ***
Kragen Sitaker
> I have a follow-up question though. The project I'm currently
> working on is well suited for third-party contributions; it makes
> sense for others to add modules if they want to. If my code is
> released under, say, the GPL, what happens when someone else wants
> to contribute to it? Does the new code have to be GPL too? Or
> GPL-compatible?
Briefly, yes.
The GNU General Public License does not allow other people to
incorporate your program into a program that is licensed more
restrictively. So if someone writes a module they want to become part
of your program, they must either grant people the right to use, copy,
modify, and redistribute their code under the GNU GPL or get you to
grant a more liberal license to your code.
Other ('non-copyleft') licenses, such as the BSD license, don't impose
this restriction. As a result, if you license your code under the BSD
license, someone can add some proprietary modification, run py2exe on
it, and sell it under a standard proprietary-software EULA for $500 a
pop: "Purchaser agrees not to decompile, reverse-engineer, or
disassemble the Software."
Some people see this as an advantage of non-GPL licenses like
Python's, which result in the software being used more widely; other
people see this as an advantage of the GPL, which results in all the
users of the software having the freedoms to use, copy, modify, and
redistribute it.
Bernhard Reiter
Hans Nowak <wu...@earthlink.net> writes:
> The project I'm currently working on
> is well suited for third-party contributions;
> it makes sense for others to add modules if they want to.
> If my code is released under, say, the GPL, what
> happens when someone else wants to contribute to it? Does the
> new code have to be GPL too? Or GPL-compatible?
The new code has to be GPL compatible so that somebody can include
it in a joined distribution which will be under GPL.
Bernhard
--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)
Peter Hansen
> On Sun, 25 Nov 2001 23:42:20 GMT, Hans Nowak <wu...@earthlink.net> wrote:
> >Then there's a second point: I see that many projects use version
> >substantial benefits over versioning your files by hand, aside from
> >having a repository through which you can undo changes?
>
> Depends. If only one person is working on the project, CVS is overkill.
>
> If lots of people are working on it, it's a good idea.
My opinion: a good idea if only one person is working on it.
Mandatory if more than one work on it.
When I was a wee little hacker, I knew nothing about version
control and kept everything "carefully" arranged in different
folders. When I wanted to test a new idea, I would make a
copy of the contents of the folder. When I wanted to make
a new version, I would zip up (actually, zoo) the files and
use a name based on the date. Sounds simple, but as time
went by I ended up with literally dozens of folders, subfolders,
zoo'd and zip'd files (and some .arc, .jar, and probably
others), scattered all over the place. No hope ever of
recovering from this situation. Now I use cvs (via WinCVS),
even for little two-file programs I just whip up. The initial
investment makes it appear overkill, but after that it
pays you back with every use.
--
----------------------
Peter Hansen, P.Eng.
pe...@engcorp.com
Paul Rubin
> > Depends. If only one person is working on the project, CVS is overkill.
> >
> > If lots of people are working on it, it's a good idea.
>
> My opinion: a good idea if only one person is working on it.
>
> Mandatory if more than one work on it.
CVS is a layer over RCS that lets multiple people work on the same
files at the same time, and automatically merges their changes at
check-in. I don't see any point to it for a one person project. RCS
is a lot simpler. I use RCS for one-person projects and couldn't live
without it. But I haven't found a reason to deal with the increased
complexity of CVS. Is there one?
Peter Hansen
I don't know much (anything) about how scalable RCS might
be, but I tried it briefly years ago and never found it
of much use at the time. That may have been before I was
really ready for decent revision control.
I suspect that CVS does have some clear advantages, however,
and those might be in the following areas:
- compatibility with most open-source projects, at
least in terms of the reusability of knowledge
- multiple directory handling
- support for decent client-server interaction via
pserver among other things
- GUI support via WinCVS and others (e.g. on Mac)
- actively maintained (maybe RCS is too?)
Those suggestions aside, I certainly didn't mean
to suggest that CVS is the only viable option for
single-developer use! I really only meant to suggest
that revision control itself is of significant
value even for one-person "teams", and you obviously
agree. :)
I wouldn't try to push somebody from RCS to CVS
(or vice versa) without knowing more.
Kragen Sitaker
> CVS is a layer over RCS that lets multiple people work on the same
> files at the same time, and automatically merges their changes at
> check-in. I don't see any point to it for a one person project. RCS
> is a lot simpler. I use RCS for one-person projects and couldn't live
> without it. But I haven't found a reason to deal with the increased
> complexity of CVS. Is there one?
* storing your repository on a remote machine
* having multiple copies of the same files in different places at the same time
(e.g. my laptop, my desktop)
* cvs annotate
* triggers (e.g. update-on-commit)
* cvs -n -q update, which tells you which files are modified and which
aren't under version control
* CVS GUIs --- e.g. WinCVS
Still, I mostly use RCS for things like .bashrc and .xsession. It's
less trouble; I don't have to set up a repository and set up
update-on-commit. I just ci -l.
Paul Boddie
>
> CVS is a layer over RCS that lets multiple people work on the same
> files at the same time, and automatically merges their changes at
> check-in. I don't see any point to it for a one person project. RCS
> is a lot simpler. I use RCS for one-person projects and couldn't live
> without it. But I haven't found a reason to deal with the increased
> complexity of CVS. Is there one?
It's been ages since I last worked with RCS, but I did work with SCCS
extensively not so long ago and I would say that there are numerous
advantages to using CVS in preference to the other two.
For example, it's possible to change into another directory and check
out a completely different release to the one you're working on
(useful for testing stuff), or even the same release (useful for
putting release packages together), whilst keeping your existing work
separate and unaffected. These activities may seem to be things that
only multi-person projects would demand, but by focusing on the
different roles in a project, things can become a lot more convenient
(and reliable) for one person working on their own. After all,
software development rarely involves only one kind of activity.
As far as ease of use is concerned, I wouldn't say that CVS is really
any harder than RCS, although the more interesting features of CVS can
take time to master. However, I doubt that people would attempt
similar or equivalent things in RCS so readily. If you can master
"ci", "cout" and "rcsdiff", you can surely master "cvs commit", "cvs
update"/"cvs checkout" and "cvs diff".
Paul
David Bolen
> CVS is a layer over RCS that lets multiple people work on the same
> files at the same time, and automatically merges their changes at
> check-in. I don't see any point to it for a one person project. RCS
> is a lot simpler. I use RCS for one-person projects and couldn't live
> without it. But I haven't found a reason to deal with the increased
> complexity of CVS. Is there one?
Actually, CVS hasn't really been a layer above RCS for some time now,
although it did start that way. The file formats are compatible, but
CVS has internal routines for handling I/O to them nowadays.
And yes, I routinely stick with CVS for all my personal projects as
well. The automatic recursion and manipulation of full project
directories are much more efficient than trying to do it with RCS as
soon as you get above one or two files. It's also more convenient to
have a single repository for all my personal work rather than RCS
subdirectories strewn around the filesystem, or individual ",v" files
within source directories.
I may sometimes do direct ci/co with RCS if I'm truly working on a
single standlone file, but generally even then I just create a new CVS
directory to work from.
--
-- David
--
/-----------------------------------------------------------------------\
\ David Bolen \ E-mail: db...@fitlinxx.com /
| FitLinxx, Inc. \ Phone: (203) 708-5192 |
/ 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \
\-----------------------------------------------------------------------/
Jeff Shannon
With all this discussion of CVS, I have a question that I've not been able to
find a satisfactory answer to, myself.
My current place of employment does not use any significant form of version
control. Due to the nature of most of our codebase, using CVS for it would
be unrealistic anyhow. Despite all of this, I would like to begin using CVS
for those projects that I can, even if I'm the only one using it. The
problem with this, is that I don't have access to a Unix/Linux server to
install CVS on (our one Unix server is host to our virtual-OS (non-SQL)
database, and I don't think I could convince anyone to install anything
unnecessary there <wink>). What I'd really like, is a version (or clone) of
CVS that will allow me to use a local repository under Windows. Does any
such thing exist? (I'm very frustrated, trying to teach myself good software
engineering practices in a workplace that doesn't support that at all... )
Jeff Shannon
Technician/Programmer
Credit International
Peter Hansen
There is a version of CVS for Windows, and there is WinCVS (GUI),
either of which works nicely with a local repository under Windows.
In fact, up until about nine months ago, we were using one of the
shared network drives on the Windows network to store the repository,
keeping our fingers crossed (and doing backups frequently) to prevent
someone from just overwriting the files.
It worked well. When the time came finally to set up the pserver
on our Intranet box (Redhat 7.0) I just copied the directory tree
over with scp and we've continued from there ever since.
Check on google for the CVS site...
By the way, what is it about the nature of your codebase which
makes using CVS unrealistic? If it's source, you should be
able to use CVS to control it.
Gerhard Häring
>
> With all this discussion of CVS, I have a question that I've not been able to
> find a satisfactory answer to, myself.
>
> My current place of employment does not use any significant form of version
> control.
> Due to the nature of most of our codebase, using CVS for it would be
> unrealistic anyhow.
If this is because it's a Micro$oft shop, Visual Source"safe" is a reasonable
version control software. Btw. CVS also has deficiencies like no history of
meta-operations like file moving/renaming, etc.
> Despite all of this, I would like to begin using CVS
> for those projects that I can, even if I'm the only one using it. The
> problem with this, is that I don't have access to a Unix/Linux server to
> install CVS on (our one Unix server is host to our virtual-OS (non-SQL)
> database, and I don't think I could convince anyone to install anything
> unnecessary there <wink>). What I'd really like, is a version (or clone) of
> CVS that will allow me to use a local repository under Windows. Does any
> such thing exist?
Either use Cygwin, which is a pretty complete Unix emulation for Windows. And
yes, it has CVS, too. http://www.cygwin.com/
Or use CVSNT (http://www.cvsnt.org/), which is a native win32 CVS server (and
client).
There are also nice CVS GUIs for Windows: http://www.cvsgui.org/ and my
favourite http://www.cvsgui.org/TortoiseCVS/index.shtml which is an Explorer
plug-in that let's you use CVS from the standard Windows Explorer.
> (I'm very frustrated, trying to teach myself good software
> engineering practices in a workplace that doesn't support that at all... )
I'd just try to educate my co-workers. That's what I currently do :) Maybe you
could also mention how this or that could have been avoided had there been a
version control system/regression tests/any QA at all/proper documentation,
etc.
Gerhard
--
mail: gerhard <at> bigfoot <dot> de registered Linux user #64239
web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id 86AB43C0
public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))
David Bolen
> If this is because it's a Micro$oft shop, Visual Source"safe" is a reasonable
> version control software. Btw. CVS also has deficiencies like no history of
> meta-operations like file moving/renaming, etc.
(minor MS-bash .. Definitely agree on the CVS shortcomings, but but at
least CVS handles branching reasonably)
(...)
> Or use CVSNT (http://www.cvsnt.org/), which is a native win32 CVS server (and
> client).
I'd agree on both of the above points. We're primarily an MS-shop and
most of our source is in SourceSafe (it really does integrate the best
with the MS tools and certainly provides a nicer interface for most
MS-based developers).
But we also keep some of our large network projects in CVS. Partially
because the team working on them are Unix-background and familiar with
it but partially since it's really appropriate in some cases (such as
tracking internal versions of third party sources).
While stock CVS can compile under Cygwin (which we also use), the nice
things about CVSNT is that it easily runs as a service without any
shims, and that it supports NT authentication. So you run it on your
server, and then use :ntserver:.... as your CVSPATH and it uses the
existing NT authentication system.
> There are also nice CVS GUIs for Windows: http://www.cvsgui.org/ and my
> favourite http://www.cvsgui.org/TortoiseCVS/index.shtml which is an Explorer
> plug-in that let's you use CVS from the standard Windows Explorer.
From my perspective, I haven't been overly enthusiastic about WinCVS
(the cvsgui link), at least not enough to try to promote its use.
It's not bad, but I found the command line much more productive.
Haven't seen the Explorer plug in, so I'll have to check that out.
To the original poster - regardless of SourceSafe or CVS, get
something. Doing any professional development without source code
control is working without a net. The benefits are great and the
overhead relatively small. I can't imagine not using one even for the
smallest of my own personal projects at this point, simply because it
provides so much in terms of functionality over the course of
development.
Laura Creighton
looking for something which is not file oriented, or which is better
able to handle multiple people editing the same file on the same day.
Just a way to insist 'I just moved that class into its own file.
Nobody gets to reinsert their old hacked versions of this class _back_
into this file -- if you are changing this class you now need _that file_'
would be incredibly useful.
Laura Creighton
Thomas Heller
Sometimes I hear some rumour about Perforce, but I never tried it.
Thomas
Roy Smith
> CVS is a layer over RCS that lets multiple people work on the same
> files at the same time, and automatically merges their changes at
> check-in.
That is certainly the theory, but I'm not sure how well it works in
practice.
I use CVS on a fairly large project (my team of 10 people deals with about
2500 source files, and that's about half the whole project). For us, the
real advantage of CVS vs. RCS is the ability to keep our sources on a
remote server (yes, we could probably do the same thing with RCS over NFS,
but we're not big NFS fans). The relatively new http front end to CVS also
makes a really cool source browser.
Although we do not enforce it with locked checkouts, we really prefer to
work in the "one person editing a file at a time" mode. If we ever go to
check a file back in and discover it's got changes to merge from somebody
else's work, we generally consider that a problem, and at the very least,
manually verify that the merged changes make sense.
We organize our stuff so it's very modular -- lots of small files, each
with a very self-contained bit of code. If two different people find
themselves working on the same source file at the same time, it's more
likely to be a breakdown in intra-team communication than anything else. I
could see how with a project organized differently, that might not be the
case.
But, to make a long story short, for a small project, with just one person
working on the code, and more importantly, will all the development
happening on a single machine, RCS should do just fine and it's probably
simplier to learn and set up.
Does anybody actually use SCCS any more?
We've been watching subversion (http://subversion.tigris.org/) with
interest, but I'm guessing it's six months to a year before it'll be stable
enough to risk running a major production project on it.
Karl M. Syring
There is a whole slew of stuff (http://www.cmtoday.com/yp/free.html).
(Fightin' with CVS to completely remove a cancerous side branch)
Karl M. Syring
Fredrik Lundh
> Sometimes I hear some rumour about Perforce, but I never tried it.
not sure it supports Laura's specific need, but generally
speaking, Perforce rules.
(what Python programmer can resist a system that can
generate all output as marshalled Python objects? ;-)
</F>
Chris Barker
> I would like to begin using CVS
> for those projects that I can, even if I'm the only one using it. The
> problem with this, is that I don't have access to a Unix/Linux server to
> install CVS on
It would be pretty easy to use any old Intel box, put Linux on it, and
run it as your CVS server. If that's all it was doing, you could run it
on a old 386! Then you might be able to convince your collegues of the
glory of Linux, along with the glory of CVS and version control!
Personally, I work in a mostly Mac, some Windows shop. I am the only one
running Linux, but I manage a project with CVS, and just run it on my
desktop box. It works just great.
-Chris
--
Christopher Barker,
Ph.D.
ChrisH...@home.net --- --- ---
http://members.home.net/barkerlohmann ---@@ -----@@ -----@@
------@@@ ------@@@ ------@@@
Oil Spill Modeling ------ @ ------ @ ------ @
Water Resources Engineering ------- --------- --------
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------
Hung Jung Lu
> Gerhard =?unknown-8bit?Q?H=E4ring?= <gh_pyt...@gmx.de> writes:
> > If this is because it's a Micro$oft shop, Visual Source"safe" is a reasonable
> > version control software. Btw. CVS also has deficiencies like no history of
> > meta-operations like file moving/renaming, etc.
> (minor MS-bash .. Definitely agree on the CVS shortcomings, but but at
> least CVS handles branching reasonably)
> From my perspective, I haven't been overly enthusiastic about WinCVS
> (the cvsgui link), at least not enough to try to promote its use.
I'll speak for one here, on my own experience. I honestly tried very
hard to switch from SourceSafe to CVS. But the CVS world just seemed
kind of immature for Windows platform, and the disdain attitude of
some CVS developers towards the Windows platform did not help. After
wasting some time on various Windows adaptations of CVS, I gave up.
Enterprise Visual Studio is not that expensive anymore (especially if
you go to eBay). Given the long track record of CVS, I really don't
understand why the windows adaptation is still so primitive, why
documentations are so badly written. Website CVS resources are so
badly organized, too. I know CVS is free, but it ended up costing me
development time and money. I am sure CVS will get better, but I'll
give it a few more years. Meanwhile, I use SourceSafe.
Hung Jung
David Bolen
> (...) Given the long track record of CVS, I really don't
> understand why the windows adaptation is still so primitive, why
> documentations are so badly written.
It's probably one of those open-source laws of supply and demand, and
how there's often a mismatch between the two. I'm a heavy CVS user
and the _last_ think I care about is a nice GUI for it. I'm
completely command line (even on Windows) and perfectly happy :-)
But I'm sure there are lots of folks who would prefer the GUI; perhaps
there are fewer of them that are developers who want to work on CVS
itself.
Or perhaps since there are products such as SourceSafe that cater to
that audience, there's less of a demand to try to move CVS into that
space.
> (...) . I am sure CVS will get better, but I'll
> give it a few more years. Meanwhile, I use SourceSafe.
I don't know how much to expect over time - CVS has been around quite
a while (at least 10+ years) and I'd guess is unlikely to undergo
major shifts quickly at this point, but perhaps I'm wrong.
Justin Sheehy
> Sometimes I hear some rumour about Perforce, but I never tried it.
Perforce is very nice, but not free if you want more than two users.
-Justin
Peter Hansen
>
> I'll speak for one here, on my own experience. I honestly tried very
> hard to switch from SourceSafe to CVS. But the CVS world just seemed
> kind of immature for Windows platform, and the disdain attitude of
> some CVS developers towards the Windows platform did not help. After
> wasting some time on various Windows adaptations of CVS, I gave up.
Our experience was the opposite. I had used Starteam in the past and
found it very effective, but they changed their licensing and for my
new group it would have been prohibitively expensive. We evaluated
SourceSafe extensively, but after fighting it (crashes, lost data,
and missing features) for months, I finally gave in to the advice
of a co-op student who insisted that CVS was quite up to the task.
I'm very glad to see him proven right.
Our conclusion was that while SourceSafe *might* be suitable for
a one-person situation, it was absolutely unsuited, and downright
*dangerous*, for a team environment. I feel that with CVS our
data is *much* more secure, and we've had effectively no issues
such as crashing. (As I mentioned elsewhere, we are now running
pserver on Linux and using WinCVS for Windows clients, plus some
shell Linux clients. Perhaps Hung's experience with CVS on
Windows was several years ago, and things might have changed.)
But of course YMMV.
Brent Stroh
>Although we do not enforce it with locked checkouts, we really prefer to
>work in the "one person editing a file at a time" mode. If we ever go to
>check a file back in and discover it's got changes to merge from somebody
>else's work, we generally consider that a problem, and at the very least,
>manually verify that the merged changes make sense.
As you should. CVS doesn't know anything about C++, Java, whatever. It
merges text files, regardless of the contents.
A tool is not a substitute for a development process, or for understanding
of what a piece of code should be doing.
Roy Smith
> My current place of employment does not use any significant form of version
> control.
How the heck do they have any idea which end is up?
> Due to the nature of most of our codebase, using CVS for it would
> be unrealistic anyhow.
Could you expand on that? Are you saying that specifically CVS won't work
for your codebase, or that version control in general won't work? Either
way, I'm curious to hear why you think that.
phil hunt
>
>I don't know how much to expect over time - CVS has been around quite
>a while (at least 10+ years) and I'd guess is unlikely to undergo
>major shifts quickly at this point, but perhaps I'm wrong.
CVS itself probably won't. GUI and web front ends probably will.
Bernhard Reiter
still in development, but looks promissing.
In article <mailman.1007037345...@python.org>,
--
Hung Jung Lu
> Our conclusion was that while SourceSafe *might* be suitable for
> a one-person situation, it was absolutely unsuited, and downright
> *dangerous*, for a team environment.
I know that from experience. SourceSafe is not safe, I've experienced
crash before, in an environment of about 30 programmers. (Visual
Studio 5, a few years ago already.) However, after recovery, and using
a lot more disk space, the problem did not reoccur, ever.
(Your comment on "SourceSafe *might* be suitable for a one-person
situation" may really hurt the pride of Micro$oft, given that Visual
SourceSafe is used in gigantic corporations, often up to hundreds of
programmers at the same time.)
If I considered switching to CVS, it's because I don't trust
SourceSafe very much anymore. However, my experience with CVS was
quite disappointing. So, I still rely on SourceSafe, but just with
additional measures for backups.
> shell Linux clients. Perhaps Hung's experience with CVS on
> Windows was several years ago, and things might have changed.)
No, it was just two months ago. Just compare documentation style of
CVS materials from www.cvshome.org with the documentation style of
Python. A whole world of difference. CVS documentation is really bad,
in my opinion. Unprofessional and immature, if I may add. I have tried
CVS years ago, I have tried CVS two months ago. My opinion is, if I
get frustrated, thousands more people out there probably have had the
same experience.
Enterprise Visual Studio nowadays goes for $300 or less. It sets up in
matter of minutes. In a world where time is money, trying to convince
the Windows world to use CVS is just a tough sell. CVS is still much
attached to the Unix world. As I said, I'd give it a few more years.
It'll get better.
Hung Jung