cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Tue, 2005-09-06 at 18:24 +0200, djurban wrote: > Author: djurban Date: Tue Sep 6 16:24:57 2005 GMT > Module: SOURCES Tag: HEAD > Log message: > - from ghostscript.spec's HEAD > - lost the logs, but i dont have time to mail the commands for all those > files to cvs admins [...] let's start new war... what about moving repo to svn? wrobell <[EMAIL PROTECTED]> ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Tue, Sep 06, 2005 at 05:32:50PM +0100, wrobell wrote: > let's start new war... > > what about moving repo to svn? Any reasons? SVN sucks a big one. -- --= Michal Kochanowicz =--==--==BOFH==--==--= [EMAIL PROTECTED] =-- --= finger me for PGP public key or visit http://michal.waw.pl/PGP =-- --==--==--==--==--==-- Vodka. Connecting people.--==--==--==--==--==-- A chodzenie po górach SSIE!!! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Tue, 06 Sep 2005, wrobell wrote: > On Tue, 2005-09-06 at 18:24 +0200, djurban wrote: > > Author: djurban Date: Tue Sep 6 16:24:57 2005 GMT > > Module: SOURCES Tag: HEAD > > Log message: > > - from ghostscript.spec's HEAD > > - lost the logs, but i dont have time to mail the commands for all those > > files to cvs admins > [...] > > let's start new war... > > what about moving repo to svn? Forget it. SVN is really poor choice for SPECS/SOURCES. Besides, its taging/branching scheme just sucks client-side. Janek -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Tue, Sep 06, 2005 at 05:32:50PM +0100, wrobell wrote: > On Tue, 2005-09-06 at 18:24 +0200, djurban wrote: > > Author: djurban Date: Tue Sep 6 16:24:57 2005 GMT > > Module: SOURCES Tag: HEAD > > Log message: > > - from ghostscript.spec's HEAD > > - lost the logs, but i dont have time to mail the commands for all those > > files to cvs admins > [...] > > let's start new war... > > what about moving repo to svn? Nice try ;) (Probably) Too much effort, (probably) not enough gain. Why? Svn cp/mv, or atomic commits aren't crucial for me. And oh, I'd miss those 1.441.2.1178 style revisions :) -- http://www.mysza.eu.org/ | Everybody needs someone sure, someone true, PLD Linux developer | Everybody needs some solid rock, I know I do. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Tue, 2005-09-06 at 18:46 +0200, Michal Kochanowicz wrote: > On Tue, Sep 06, 2005 at 05:32:50PM +0100, wrobell wrote: > > let's start new war... > > > > what about moving repo to svn? > > Any reasons? SVN sucks a big one. svn diff without performing connection to remote server. i think that cvs really sucks. so... any alternatives? wrobell <[EMAIL PROTECTED]> ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Tue, Sep 06, 2005 at 05:32:50PM +0100, wrobell wrote: > what about moving repo to svn? No. wolf -- Bartek . - Diamagnetyki, cóż to za stwory? Taudul : .: w o l f @ p l d - l i n u x . o r g.:. http://wolf.valkyrie.one.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Tue, 06 Sep 2005, wrobell wrote: > On Tue, 2005-09-06 at 18:46 +0200, Michal Kochanowicz wrote: > > On Tue, Sep 06, 2005 at 05:32:50PM +0100, wrobell wrote: > > > let's start new war... > > > > > > what about moving repo to svn? > > > > Any reasons? SVN sucks a big one. > > svn diff without performing connection to remote server. At the cost of keeping ALL tags/branches locally. You're joking. [EMAIL PROTECTED] rpm]$ du -hs SOURCES SPECS 959MSOURCES 63M SPECS > i think that cvs really sucks. so... any alternatives? There is nothing better :/ Janek -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Tue, Sep 06, 2005 at 06:07:00PM +0100, wrobell wrote: > On Tue, 2005-09-06 at 18:46 +0200, Michal Kochanowicz wrote: > > On Tue, Sep 06, 2005 at 05:32:50PM +0100, wrobell wrote: > > > let's start new war... > > > > > > what about moving repo to svn? > > > > Any reasons? SVN sucks a big one. > > svn diff without performing connection to remote server. > > i think that cvs really sucks. so... any alternatives? git maybe? ok, just joking... -- http://www.mysza.eu.org/ | Everybody needs someone sure, someone true, PLD Linux developer | Everybody needs some solid rock, I know I do. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Tue, 2005-09-06 at 19:27 +0200, Jan Rekorajski wrote: > At the cost of keeping ALL tags/branches locally. You're joking. > > [EMAIL PROTECTED] rpm]$ du -hs SOURCES SPECS > 959MSOURCES > 63M SPECS Obviously svn makes no sense with such file organization (in two directories). To allow reasonable branching, each package would have to have a directory of its own. Which is a good idea anyway, but probably it's not worth changing now. -- Paweł Sakowski <[EMAIL PROTECTED]> PLD Linux Distribution ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Tue, 6 Sep 2005, wrobell wrote: > > Author: djurban Date: Tue Sep 6 16:24:57 2005 GMT > > Module: SOURCES Tag: HEAD > > Log message: > > - from ghostscript.spec's HEAD > > - lost the logs, but i dont have time to mail the commands for all > > those files to cvs admins > [...] > > let's start new war... > > what about moving repo to svn? no. If you really want to move - find something that gives _real_ advantages. -- pozdr. Paweł Gołaszewski jid:bluesjabbergdapl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
Paweł Sakowski wrote: > On Tue, 2005-09-06 at 19:27 +0200, Jan Rekorajski wrote: > >>At the cost of keeping ALL tags/branches locally. You're joking. >> >>[EMAIL PROTECTED] rpm]$ du -hs SOURCES SPECS >>959MSOURCES >>63M SPECS > > > Obviously svn makes no sense with such file organization (in two > directories). To allow reasonable branching, each package would have to > have a directory of its own. Which is a good idea anyway, but probably > it's not worth changing now. But it would be a really big problem for people like qboosh. Probably the best choice would be to design something ourselves. ;-) -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Tue, 2005-09-06 at 20:30 +0200, Paweł Gołaszewski wrote: > On Tue, 6 Sep 2005, wrobell wrote: > > > Author: djurban Date: Tue Sep 6 16:24:57 2005 GMT > > > Module: SOURCES Tag: HEAD > > > Log message: > > > - from ghostscript.spec's HEAD > > > - lost the logs, but i dont have time to mail the commands for all > > > those files to cvs admins > > [...] > > > > let's start new war... > > > > what about moving repo to svn? > > no. > > If you really want to move - find something that gives _real_ advantages. can you _define_ "real advantages", please? wrobell <[EMAIL PROTECTED]> ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Tue, 2005-09-06 at 19:27 +0200, Jan Rekorajski wrote: > On Tue, 06 Sep 2005, wrobell wrote: > > > On Tue, 2005-09-06 at 18:46 +0200, Michal Kochanowicz wrote: > > > On Tue, Sep 06, 2005 at 05:32:50PM +0100, wrobell wrote: > > > > let's start new war... > > > > > > > > what about moving repo to svn? > > > > > > Any reasons? SVN sucks a big one. > > > > svn diff without performing connection to remote server. > > At the cost of keeping ALL tags/branches locally. You're joking. > > [EMAIL PROTECTED] rpm]$ du -hs SOURCES SPECS > 959MSOURCES > 63M SPECS you do _not_ have to keep _all_ tags/branches locally. > > i think that cvs really sucks. so... any alternatives? > > There is nothing better :/ with cvs we are loosing some information (i.e. deleted branches and tags). svn allows us to track it _easily_. wrobell <[EMAIL PROTECTED]> ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Wed, 07 Sep 2005, wrobell wrote: > On Tue, 2005-09-06 at 19:27 +0200, Jan Rekorajski wrote: > > On Tue, 06 Sep 2005, wrobell wrote: > > > > > On Tue, 2005-09-06 at 18:46 +0200, Michal Kochanowicz wrote: > > > > On Tue, Sep 06, 2005 at 05:32:50PM +0100, wrobell wrote: > > > > > let's start new war... > > > > > > > > > > what about moving repo to svn? > > > > > > > > Any reasons? SVN sucks a big one. > > > > > > svn diff without performing connection to remote server. > > > > At the cost of keeping ALL tags/branches locally. You're joking. > > > > [EMAIL PROTECTED] rpm]$ du -hs SOURCES SPECS > > 959MSOURCES > > 63M SPECS > > you do _not_ have to keep _all_ tags/branches locally. Really? How? Example: http://svn.pld-linux.org/svn/rc-scripts I want to keep only trunk, branches and _some_ tags, tell me how to do it, and how to prevent svn up from getting all tags. > > > i think that cvs really sucks. so... any alternatives? > > > > There is nothing better :/ > > with cvs we are loosing some information (i.e. deleted branches > and tags). svn allows us to track it _easily_. And the royal PITA, which svn is, is not worth it. Janek -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Wed, 2005-09-07 at 11:03 +0200, Jan Rekorajski wrote: > On Wed, 07 Sep 2005, wrobell wrote: > > > On Tue, 2005-09-06 at 19:27 +0200, Jan Rekorajski wrote: > > > On Tue, 06 Sep 2005, wrobell wrote: > > > > > > > On Tue, 2005-09-06 at 18:46 +0200, Michal Kochanowicz wrote: > > > > > On Tue, Sep 06, 2005 at 05:32:50PM +0100, wrobell wrote: > > > > > > let's start new war... > > > > > > > > > > > > what about moving repo to svn? > > > > > > > > > > Any reasons? SVN sucks a big one. > > > > > > > > svn diff without performing connection to remote server. > > > > > > At the cost of keeping ALL tags/branches locally. You're joking. > > > > > > [EMAIL PROTECTED] rpm]$ du -hs SOURCES SPECS > > > 959MSOURCES > > > 63M SPECS > > > > you do _not_ have to keep _all_ tags/branches locally. > > Really? How? > Example: http://svn.pld-linux.org/svn/rc-scripts > I want to keep only trunk, branches and _some_ tags, tell me how to do > it, and how to prevent svn up from getting all tags. svn up trunk? svn up tags/tagireallywant? come on... > > > > i think that cvs really sucks. so... any alternatives? > > > > > > There is nothing better :/ > > > > with cvs we are loosing some information (i.e. deleted branches > > and tags). svn allows us to track it _easily_. > And the royal PITA, which svn is, is not worth it. ... it is really hard to discuss with such arguments, which seem to be matter of taste. i think (let's skip svn for now), we need: - to keep history of tags and branches - atomic commit (so we can commit patches and specs with one move and revert it easily later if there is a need) - ability to rename specs and patches without pain and loosing information and _without_administrator_ help - check changes without making connection to remote server these are my problems with cvs. svn solves them. svn gives us some advantages. disadvantages? any real, which makes life really painful? let's talk but without "royal PITA", "i do not care for lost information", "i do not care for renaming", etc. please. then, if svn is not solution for us, then what other alternatives we can use? let's think about it, because cvs is not solution for us. wrobell <[EMAIL PROTECTED]> ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Wednesday 07 of September 2005 11:20, wrobell wrote: > i think (let's skip svn for now), we need: > - atomic commit (so we can commit patches and specs with one move > and revert it easily later if there is a need) - easier work on branches without messing the way it recently happened with some patches used by k(l)ex.spec and kernel.spec at the same time these two things are most important for me > wrobell <[EMAIL PROTECTED]> -- Arkadiusz MiśkiewiczPLD/Linux Team http://www.t17.ds.pwr.wroc.pl/~misiek/ http://ftp.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Wed, 2005-09-07 at 11:03 +0200, Jan Rekorajski wrote: > > you do _not_ have to keep _all_ tags/branches locally. > > Really? How? > Example: http://svn.pld-linux.org/svn/rc-scripts > I want to keep only trunk, branches and _some_ tags, tell me how to do > it, and how to prevent svn up from getting all tags. svn co http://svn.pld-linux.org/svn/rc-scripts/trunk rc-scripts svn co http://svn.pld-linux.org/svn/rc-scripts/tags/0.4.0.12 staroć -- Paweł Sakowski <[EMAIL PROTECTED]> PLD Linux Distribution ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Wed, 2005-09-07 at 11:30 +0200, Arkadiusz Miskiewicz wrote:
> On Wednesday 07 of September 2005 11:20, wrobell wrote:
>
> > i think (let's skip svn for now), we need:
> > - atomic commit (so we can commit patches and specs with one move
> > and revert it easily later if there is a need)
> - easier work on branches without messing the way it recently happened with
> some patches used by k(l)ex.spec and kernel.spec at the same time
>
> these two things are most important for me
I'll add checking the changes two tags/branches (both spec and patches,
either as `cvs log` or `cvs diff`). Impossible now without visual
inspection of the spec for a list of {exist,{dis,}appear}ing patches.
Oh, and it's kindda sick that we need a script of 1781 lines to simply
fetch a given version (spec+patches).
--
Paweł Sakowski <[EMAIL PROTECTED]>
PLD Linux Distribution
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Wed, Sep 07, 2005 at 10:20:54AM +0100, wrobell wrote: > > svn gives us some advantages. disadvantages? any real, which makes life > really painful? How to resolve conflict? I've got a situation: ~: vi blabla ~: svn ci blabla snv reports conflict here [fixing it manually] ~: svn ci blabla svn reports there's unresolved conflict -- Tom Pala <[EMAIL PROTECTED]> http://vfmg.sourceforge.net/ http://tccs.sourceforge.net/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Wed, 2005-09-07 at 16:51 +0200, Tomasz Pala wrote: > On Wed, Sep 07, 2005 at 10:20:54AM +0100, wrobell wrote: > > > > svn gives us some advantages. disadvantages? any real, which makes life > > really painful? > > How to resolve conflict? I've got a situation: > > ~: vi blabla > ~: svn ci blabla > snv reports conflict here svn up missing here? > [fixing it manually] > ~: svn ci blabla > svn reports there's unresolved conflict wrobell <[EMAIL PROTECTED]> ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Wed, 2005-09-07 at 16:51 +0200, Tomasz Pala wrote: > On Wed, Sep 07, 2005 at 10:20:54AM +0100, wrobell wrote: > > > > svn gives us some advantages. disadvantages? any real, which makes life > > really painful? > > How to resolve conflict? I've got a situation: > > ~: vi blabla > ~: svn ci blabla > snv reports conflict here > [fixing it manually] oops sorry... svn resolve missing here > ~: svn ci blabla > svn reports there's unresolved conflict wrobell <[EMAIL PROTECTED]> ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Wed, 07 Sep 2005, wrobell wrote: > On Wed, 2005-09-07 at 11:03 +0200, Jan Rekorajski wrote: > > Example: http://svn.pld-linux.org/svn/rc-scripts > > I want to keep only trunk, branches and _some_ tags, tell me how to do > > it, and how to prevent svn up from getting all tags. > > svn up trunk? > svn up tags/tagireallywant? > > come on... Ok, that's solved then, thanks. One more question - how to do 'svn up' in directory where I did checkouts so it will update all checked subdirs? With cvs all I need to do is `mkdir CVS ; echo $CVSROOT > CVS/Root ; cvs up` A recipe for svn much appreciated :) > > And the royal PITA, which svn is, is not worth it. > > ... it is really hard to discuss with such arguments, which seem > to be matter of taste. > > i think (let's skip svn for now), we need: > - to keep history of tags and branches ok, I guess all versioning systems must have it, or do you mean dead/deleted tags and branches? What for? > - atomic commit (so we can commit patches and specs with one move > and revert it easily later if there is a need) Example? > - ability to rename specs and patches without pain and loosing > information and _without_administrator_ help Maybe, but do we really do this that often? > - check changes without making connection to remote server And svn solves it how? > these are my problems with cvs. svn solves them. > > svn gives us some advantages. disadvantages? any real, which makes life > really painful? let's talk but without "royal PITA", "i do not care > for lost information", "i do not care for renaming", etc. please. One BIG disadvantege is that we will have to reorganize the entire repo into "one package" = "one svn dir" layout. And then it's either a fscking lot of copying svn-local-repo <-> ~/rpm/* or constant editing of ~/.rpmmacros. With current layout I can just checkout entire SPECS and SOURCES and work with any package on any branch easily. And then, what "lost information"? And the argument about renaming is just making me laugh, we have more than 9400 specs, we needed to rename how much of them? 10? 20? Come on. > then, if svn is not solution for us, then what other alternatives > we can use? let's think about it, because cvs is not solution > for us. Why it is not? I work with it from the beggining and I don't feel any need to switch, I haven't yet seen a versioning system that would give enough advantages that I'd consider switching. Janek -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Thu, 2005-09-08 at 01:53 +0200, Jan Rekorajski wrote:
> On Wed, 07 Sep 2005, wrobell wrote:
>
> > On Wed, 2005-09-07 at 11:03 +0200, Jan Rekorajski wrote:
> > > Example: http://svn.pld-linux.org/svn/rc-scripts
> > > I want to keep only trunk, branches and _some_ tags, tell me how to do
> > > it, and how to prevent svn up from getting all tags.
> >
> > svn up trunk?
> > svn up tags/tagireallywant?
> >
> > come on...
>
> Ok, that's solved then, thanks. One more question - how to do 'svn up' in
> directory where I did checkouts so it will update all checked subdirs?
> With cvs all I need to do is `mkdir CVS ; echo $CVSROOT > CVS/Root ; cvs up`
> A recipe for svn much appreciated :)
1. create your own local repo
2. checkout it
3. svn propedit svn:externals .
4. add tags, branches, whatever
5. svn up
the advantage: you will never fsck up anything with cvs up -A
(imho, but not tested with cvs)
> > > And the royal PITA, which svn is, is not worth it.
> >
> > ... it is really hard to discuss with such arguments, which seem
> > to be matter of taste.
> >
> > i think (let's skip svn for now), we need:
> > - to keep history of tags and branches
>
> ok, I guess all versioning systems must have it, or do you mean
> dead/deleted tags and branches? What for?
yes. deleted tags and branches. i.e. when you merge DEVEL, delete
it, then for some reason you want to compare HEAD with DEVEL
(i.e. something went wrong while merging).
> > - atomic commit (so we can commit patches and specs with one move
> > and revert it easily later if there is a need)
>
> Example?
svn ci -m "patches updated for 3.0" \
SPECS/tetex.spec SOURCES/teTeX*patch
and then, later, you can easily see what exact changes
where made. good luck with cvs.
> > - ability to rename specs and patches without pain and loosing
> > information and _without_administrator_ help
>
> Maybe, but do we really do this that often?
not often. but happens from time to time. again: not only specs,
but very useful for renaming patches.
> > - check changes without making connection to remote server
>
> And svn solves it how?
maybe i should put it this way: "check _local_ changes..."
svn diff|status|revert
http://svnbook.red-bean.com/en/1.1/apas03.html
> > these are my problems with cvs. svn solves them.
> >
> > svn gives us some advantages. disadvantages? any real, which makes life
> > really painful? let's talk but without "royal PITA", "i do not care
> > for lost information", "i do not care for renaming", etc. please.
>
> One BIG disadvantege is that we will have to reorganize the entire repo
> into "one package" = "one svn dir" layout. And then it's either a
> fscking lot of copying svn-local-repo <-> ~/rpm/* or constant editing of
> ~/.rpmmacros. With current layout I can just checkout entire SPECS and
> SOURCES and work with any package on any branch easily.
i think, that we are able to create such structure (and even structures)
that it will be as easy as it is now and it will give us more options
(so yes, i see rpm/{SPECS,SOURCES} as _not_ obsoleted)
> And then, what "lost information"? And the argument about renaming is
> just making me laugh, we have more than 9400 specs, we needed to rename
> how much of them? 10? 20? Come on.
it is sick to ask admin, isn't it? please consider renaming of patches
too.
> > then, if svn is not solution for us, then what other alternatives
> > we can use? let's think about it, because cvs is not solution
> > for us.
>
> Why it is not? I work with it from the beggining and I don't feel any
> need to switch, I haven't yet seen a versioning system that would give
> enough advantages that I'd consider switching.
i wrote reasons in other post. and there are people who think we
should switch and they (we) have real problems which would be
solved then.
wrobell <[EMAIL PROTECTED]>
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On 9/6/05, Jan Rekorajski <[EMAIL PROTECTED]> wrote: > On Tue, 06 Sep 2005, wrobell wrote: > > > On Tue, 2005-09-06 at 18:46 +0200, Michal Kochanowicz wrote: > > > On Tue, Sep 06, 2005 at 05:32:50PM +0100, wrobell wrote: > > > > let's start new war... > > > > > > > > what about moving repo to svn? > > > > > > Any reasons? SVN sucks a big one. > > > > svn diff without performing connection to remote server. > > At the cost of keeping ALL tags/branches locally. You're joking. Why would anyone store all branches and tags locally? Tagging can be done by svn cp http://somewhere/trunk http://somewhere/tags/some-tag and moving to a new branch can be done with svn switch http://somewhere/branches/some-branch. The results are much like with cvs. -- Michal Moskal, http://nemerle.org/~malekith/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Tue, Sep 06, 2005 at 08:29:06PM +0200, Paweł Sakowski wrote: > On Tue, 2005-09-06 at 19:27 +0200, Jan Rekorajski wrote: > > At the cost of keeping ALL tags/branches locally. You're joking. > > > > [EMAIL PROTECTED] rpm]$ du -hs SOURCES SPECS > > 959MSOURCES > > 63M SPECS > > Obviously svn makes no sense with such file organization (in two > directories). To allow reasonable branching, each package would have to > have a directory of its own. Which is a good idea anyway, but probably > it's not worth changing now. How would I make "cvs up SPECS" (without getting any SOURCES) then? -- Jakub Boguszhttp://qboosh.cs.net.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Thursday 08 of September 2005 20:27, Jakub Bogusz wrote: > On Tue, Sep 06, 2005 at 08:29:06PM +0200, Paweł Sakowski wrote: > > On Tue, 2005-09-06 at 19:27 +0200, Jan Rekorajski wrote: > > > At the cost of keeping ALL tags/branches locally. You're joking. > > > > > > [EMAIL PROTECTED] rpm]$ du -hs SOURCES SPECS > > > 959MSOURCES > > > 63M SPECS > > > > Obviously svn makes no sense with such file organization (in two > > directories). To allow reasonable branching, each package would have to > > have a directory of its own. Which is a good idea anyway, but probably > > it's not worth changing now. > > How would I make "cvs up SPECS" (without getting any SOURCES) then? Not so easy as in cvs. for pkg in `svn ls http://.../packages/`; do do whatever you need done -- Arkadiusz MiśkiewiczPLD/Linux Team http://www.t17.ds.pwr.wroc.pl/~misiek/ http://ftp.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Thu, 08 Sep 2005, Arkadiusz Miskiewicz wrote: > On Thursday 08 of September 2005 20:27, Jakub Bogusz wrote: > > On Tue, Sep 06, 2005 at 08:29:06PM +0200, Paweł Sakowski wrote: > > > On Tue, 2005-09-06 at 19:27 +0200, Jan Rekorajski wrote: > > > > At the cost of keeping ALL tags/branches locally. You're joking. > > > > > > > > [EMAIL PROTECTED] rpm]$ du -hs SOURCES SPECS > > > > 959MSOURCES > > > > 63M SPECS > > > > > > Obviously svn makes no sense with such file organization (in two > > > directories). To allow reasonable branching, each package would have to > > > have a directory of its own. Which is a good idea anyway, but probably > > > it's not worth changing now. > > > > How would I make "cvs up SPECS" (without getting any SOURCES) then? > Not so easy as in cvs. > > for pkg in `svn ls http://.../packages/`; do > do whatever you need > done Bzzt, argument line too long... Try again ;> Janek -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Thursday 08 of September 2005 23:10, Jan Rekorajski wrote: > > for pkg in `svn ls http://.../packages/`; do > > do whatever you need > > done > > Bzzt, argument line too long... > Try again ;> Yeah, then show me how to fetch single app with spec + patches using command line - cvs and sh only. > Janek -- Arkadiusz MiśkiewiczPLD/Linux Team http://www.t17.ds.pwr.wroc.pl/~misiek/ http://ftp.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On 9/8/05, Jan Rekorajski <[EMAIL PROTECTED]> wrote: > On Thu, 08 Sep 2005, Arkadiusz Miskiewicz wrote: > > > On Thursday 08 of September 2005 20:27, Jakub Bogusz wrote: > > > On Tue, Sep 06, 2005 at 08:29:06PM +0200, Paweł Sakowski wrote: > > > > On Tue, 2005-09-06 at 19:27 +0200, Jan Rekorajski wrote: > > > > > At the cost of keeping ALL tags/branches locally. You're joking. > > > > > > > > > > [EMAIL PROTECTED] rpm]$ du -hs SOURCES SPECS > > > > > 959MSOURCES > > > > > 63M SPECS > > > > > > > > Obviously svn makes no sense with such file organization (in two > > > > directories). To allow reasonable branching, each package would have to > > > > have a directory of its own. Which is a good idea anyway, but probably > > > > it's not worth changing now. > > > > > > How would I make "cvs up SPECS" (without getting any SOURCES) then? > > Not so easy as in cvs. > > > > for pkg in `svn ls http://.../packages/`; do > > do whatever you need > > done > > Bzzt, argument line too long... > Try again ;> Bzzzt, try another shell: zsh: [EMAIL PROTECTED] SPECS-all]$ ls * zsh: argument list too long: ls [EMAIL PROTECTED] SPECS-all]$ foreach f in `ls` ; do echo $f > /dev/null ; done bash: [EMAIL PROTECTED] SPECS-all]$ ls * bash: /bin/ls: Argument list too long [EMAIL PROTECTED] SPECS-all]$ foreach f in `ls` ; do echo $f > /dev/null ; done bash: syntax error near unexpected token `do' -- Michal Moskal, http://nemerle.org/~malekith/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Fri, Sep 09, 2005 at 09:14:34AM +0200, Michal Moskal wrote: > > Bzzt, argument line too long... > > Try again ;> > > Bzzzt, try another shell: > > zsh: > [EMAIL PROTECTED] SPECS-all]$ ls * > zsh: argument list too long: ls > [EMAIL PROTECTED] SPECS-all]$ foreach f in `ls` ; do echo $f > /dev/null ; > done > > bash: > [EMAIL PROTECTED] SPECS-all]$ ls * > bash: /bin/ls: Argument list too long > [EMAIL PROTECTED] SPECS-all]$ foreach f in `ls` ; do echo $f > /dev/null ; > done > bash: syntax error near unexpected token `do' for f in *; do echo $f > /dev/null; done -- --= Michal Kochanowicz =--==--==BOFH==--==--= [EMAIL PROTECTED] =-- --= finger me for PGP public key or visit http://michal.waw.pl/PGP =-- --==--==--==--==--==-- Vodka. Connecting people.--==--==--==--==--==-- A chodzenie po górach SSIE!!! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On 9/9/05, Michal Kochanowicz <[EMAIL PROTECTED]> wrote: > On Fri, Sep 09, 2005 at 09:14:34AM +0200, Michal Moskal wrote: > > > Bzzt, argument line too long... > > > Try again ;> > > > > Bzzzt, try another shell: > > > > zsh: > > [EMAIL PROTECTED] SPECS-all]$ ls * > > zsh: argument list too long: ls > > [EMAIL PROTECTED] SPECS-all]$ foreach f in `ls` ; do echo $f > /dev/null ; > > done > > > > bash: > > [EMAIL PROTECTED] SPECS-all]$ ls * > > bash: /bin/ls: Argument list too long > > [EMAIL PROTECTED] SPECS-all]$ foreach f in `ls` ; do echo $f > /dev/null ; > > done > > bash: syntax error near unexpected token `do' > > for f in *; do echo $f > /dev/null; done Ooops, stupid me, too much Nemerle ;-) Anyway it works. -- Michal Moskal, http://nemerle.org/~malekith/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Fri, Sep 09, 2005 at 12:27:58AM +0200, Arkadiusz Miskiewicz wrote: > On Thursday 08 of September 2005 23:10, Jan Rekorajski wrote: > > > > for pkg in `svn ls http://.../packages/`; do > > > do whatever you need > > > done > > > > Bzzt, argument line too long... > > Try again ;> > Yeah, then show me how to fetch single app with spec + patches using command > line - cvs and sh only. You won't do it using svn too (unless tarballs are stored in svn instead of distfiles, but I assume we don't want it). -- Jakub Boguszhttp://qboosh.cs.net.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Friday 09 of September 2005 12:58, Jakub Bogusz wrote: > > Yeah, then show me how to fetch single app with spec + patches using > > command line - cvs and sh only. > > You won't do it using svn too (unless tarballs are stored in svn > instead of distfiles, but I assume we don't want it). I didn't write about tarballs :) Of course for these we still want df. -- Arkadiusz MiśkiewiczPLD/Linux Team http://www.t17.ds.pwr.wroc.pl/~misiek/ http://ftp.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Fri, Sep 09, 2005 at 00:27:58 +0200, Arkadiusz Miskiewicz wrote: > Yeah, then show me how to fetch single app with spec + patches using command > line - cvs and sh only. cvs up builder sh builder -g foo.spec (there IS working builder). -- GoTaR gotar>http://vfmg.sourceforge.net/ http://tccs.sourceforge.net/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Fri, 2005-09-09 at 18:05 +0200, Tomasz Pala wrote:
> On Fri, Sep 09, 2005 at 00:27:58 +0200, Arkadiusz Miskiewicz wrote:
>
> > Yeah, then show me how to fetch single app with spec + patches using
> > command
> > line - cvs and sh only.
>
> cvs up builder
> sh builder -g foo.spec
>
> (there IS working builder).
and when we are talking about skipping rpm/{SPECS,SOURCES}
structure for svn repo, then we are forbidden to use scripts :)
wrobell <[EMAIL PROTECTED]>
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
[EMAIL PROTECTED] (wrobell):
>> > Yeah, then show me how to fetch single app with spec + patches using
>> > command
>> > line - cvs and sh only.
>> cvs up builder
>> sh builder -g foo.spec
>> (there IS working builder).
> and when we are talking about skipping rpm/{SPECS,SOURCES}
> structure for svn repo, then we are forbidden to use scripts :)
tell me more... :P
contributor$ pwd
/home/speedy/work/contributor/src/screen
[EMAIL PROTECTED]:/home/speedy/work/contributor/src/screen [P=screen B=HEAD
S=src]
contributor$ ls
screen.patch screen.spec
[...]
contributor$ dev build
++ building screen
++ building screen-4.0.2-20041012 (screen-4.0.2-20041012.sparc64-solaris10.rpm)
++ Source0: screen-4.0.2.tar.gz ...OK [821KB]
++ Patch0: screen.patch ...OK [6KB]
Executing(%prep):
when Source0 is missing, dev script download it, and put into
dst/screen. (cvs/svn who cares...)
--
... Zycie biegnie wahadlowym ruchem miedzy bolem i nuda,
a sa to faktycznie jego ostateczne skladniki. (Artur Schopenhauer)
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Fri, Sep 09, 2005 at 17:32:08 +0100, wrobell wrote:
> > cvs up builder
> > sh builder -g foo.spec
> >
> > (there IS working builder).
>
> and when we are talking about skipping rpm/{SPECS,SOURCES}
> structure for svn repo, then we are forbidden to use scripts :)
The difference is this scripts gets a dozen of files in a dozen
requests and one has to do 2 cvs ups.
A future script will get 10k specs with 10k svn requests, and how
many updates would require? (see p. 3)
Let's make a list of COMMON tasks (excluding trivial ones), appropriate
command sets and compare it.
1. building a package from given branch:
cvs:./builder -bb -R foo bar or ./builder -g and rpmbuild -bb
svn:!? rpm uses SPECS/SOURCES subdirs, how the hell this will work
with subdir-per-packet? Another messing script?
2. updating all resources I've checked out (having CVS/Entries.Static):
cvs:cd SPECS, cvs up; cd ../SOURCES; cvs up
svn:!?
3. fetching all specs:
cvs:cvs up
svn:
for pkg in `svn ls http://.../packages/`; do
do whatever you need
done
ohhh, it really sucks...
4. commiting changes:
cvs:cvs ci foo.spec; cd ../SOURCES; cvs ci *
svn:svn ci foo
hmmm, not so big difference, don't talk about atomic commits anymore.
Anyway - if we want this functionality, we could move SOURCES and SPECS
into higher level repo directory, so that they would be subdirs.
And now NOT COMMON ones:
5. reverting a commit:
cvs:cvs up -r X foo; mv foo{,.tmp}; cvs up -A foo; mv -f foo{.tmp,}; cvs ci
foo
svn:svn revert foo
no difference for me. Not an argument.
5. renaming
cvs:manually
svn:svn rename
well, I don't care about names, I asked to do this once or twice.
6. access to deleted TAGS
cvs:none
svn:is
who needs it anyway (OK, you need this in DEVEL example, I don't)
--
GoTaR gotar>http://vfmg.sourceforge.net/
http://tccs.sourceforge.net/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Friday 09 of September 2005 22:48, Tomasz Pala wrote:
> The difference is this scripts gets a dozen of files in a dozen
> requests and one has to do 2 cvs ups.
> A future script will get 10k specs with 10k svn requests, and how
> many updates would require? (see p. 3)
Do you know that here you are not talking about cvs vs svn but about how we
want to organise repository layout?
> Let's make a list of COMMON tasks (excluding trivial ones), appropriate
> command sets and compare it.
>
> 1. building a package from given branch:
> cvs: ./builder -bb -R foo bar or ./builder -g and rpmbuild -bb
> svn: !? rpm uses SPECS/SOURCES subdirs, how the hell this will work
> with subdir-per-packet? Another messing script?
svn co .../packages/gcc/trunk somewhere
mkdir somewhere/BUILD...
rpmbuild -bb --define _topdir somewhere
because you would have /packages/gcc/trunk/{SPECS,SOURCES}
Note that you are comparing quite ugly, huge and hardly maintainable builder
script (1787 lines) with svn. Now please do that with cvs client only without
additional stuff.
> 2. updating all resources I've checked out (having CVS/Entries.Static):
> cvs: cd SPECS, cvs up; cd ../SOURCES; cvs up
> svn: !?
Exactly the same if you use the same layout as cvs. But the point is to split
SPECS/SOURCES to nicer scheme and we should talk about that scheme. With new,
proposed scheme that would need some script to find out checked dirs and svn
up there. Well exactly the same as in cvs but we would have more dirs then.
> 3. fetching all specs:
> cvs: cvs up
> svn:
> for pkg in `svn ls http://.../packages/`; do
> do whatever you need
> done
>
> ohhh, it really sucks...
Again, you seem to think svn == /packages/something layout. These are two
separate things. With the /packages you get some things and also loose some
things.
> 4. commiting changes:
> cvs: cvs ci foo.spec; cd ../SOURCES; cvs ci *
> svn: svn ci foo
>
> hmmm, not so big difference, don't talk about atomic commits anymore.
> Anyway - if we want this functionality, we could move SOURCES and SPECS
> into higher level repo directory, so that they would be subdirs.
Atomic is the key here. You are trying to ignore that which is weird.
>
> And now NOT COMMON ones:
>
> 5. reverting a commit:
> cvs: cvs up -r X foo; mv foo{,.tmp}; cvs up -A foo; mv -f foo{.tmp,}; cvs
> ci foo svn: svn revert foo
>
> no difference for me. Not an argument.
You are talking about _single_ file. Try to revert whioe logical commit of for
example update of gcc from 4.0 to 4.0.1. It's single command with svn and
tens with cvs. Reverting one file is as easy in cvs as in svn. Well, in svn
you can revert some change without checkouting it.
svn merge -rnew:old http://
>
> 5. renaming
> cvs: manually
> svn: svn rename
>
> well, I don't care about names, I asked to do this once or twice.
You seem to do not care about a lot of important things. I remember complaints
from developers that files where copied by cvsadmin not as fast as developers
wanted.
> 6. access to deleted TAGS
> cvs: none
> svn: is
>
> who needs it anyway (OK, you need this in DEVEL example, I don't)
There is HEAD and AC-branch on some package (multiple files). You do merge to
head and then delete ac-branch. Few days later you want to revert that and...
huston we have a problem. Mainly because of no atomic commits so you need to
find out rel for each file and revert it and ... you need to do some guesses
here. Which branch, which rev, which dates.
7. work on branches
cvs: problematic if you want to work on several branches of the same files
(quite common for me, head + ac-branch); can be somehow workarounded by using
builder-like script
svn: easy, separate dirs, can view diffs easily and nicely doing merges with
for example kdiff3
8. writting scripts for scm like builder
cvs: problematic, parsing everything as strings
svn: great python bindings (for example I have repo where there is
pre-commit-hook which checks if to-be-commited php files have correct syntax
and fails otherwise... very nice)
9. doing diffs
cvs: problematic if you want to compare whole packages, easy for individual
files but only locally
svn: see how creating diff between release and branch of kdebase package is:
svn diff svn://anonsvn.kde.org/home/kde/tags/KDE/3.4.2/kdebase \
svn://anonsvn.kde.org/home/kde/branches/KDE/3.4/kdebase \
> kdebase-branch.diff
_without_ having anything beside svn client locally
We never done this in cvs pld because it was impossible and was very desired
several times when doing merges between branches.
10. with svk on top of subversion you can work disconnected. never needed it
(it could be useful for people who travel frequently)
The point here is to get nicer and easier setup to work with not just to
switch to subversion (or something else). We should think about new
repository layout, think about benefits and disadvantages. Also any switch
won't ,,just happen''. It has to be carefuly planed f
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Fri, 2005-09-09 at 22:48 +0200, Tomasz Pala wrote:
> 1. building a package from given branch:
> cvs: ./builder -bb -R foo bar or ./builder -g and rpmbuild -bb
> svn: !? rpm uses SPECS/SOURCES subdirs,[...]
Untrue. rpm uses macros. The way the macros are currently defined uses
SPECS/SOURCES subdirs. A quick-and-unperfect %(pwd) in the appropriate
place would make it:
svn co .../foo;cd foo;rpmbuild foo.spec
> 2. updating all resources I've checked out (having CVS/Entries.Static):
> cvs: cd SPECS, cvs up; cd ../SOURCES; cvs up
> svn: !?
svn up */*
> 5. reverting a commit:
> cvs: cvs up -r X foo; mv foo{,.tmp}; cvs up -A foo; mv -f foo{.tmp,}; cvs ci
> foo
Easier:
cvs up -j X -j HEAD foo;cvs ci foo
(maybe the other way round... I don't remember the exact -j syntax)
> svn: svn revert foo
You mean `svn merge -r...:... foo;svn ci foo`. `svn revert foo` is
actually an equivalent of:
rm foo;cvs up -A foo
or equivalently (a fun hack for non-binary files)
cvs diff foo|patch -R
> no difference for me. Not an argument.
The difference is that with CVS you're playing file-by-file, with svn
you can revert a whole commit{, series}, just by knowing {its,their}
revision number{,s}.
--
Paweł Sakowski <[EMAIL PROTECTED]>
PLD Linux Distribution
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Fri, 2005-09-09 at 23:28 +0200, Arkadiusz Miskiewicz wrote:
> > 6. access to deleted TAGS
> > cvs:none
> > svn:is
> >
> > who needs it anyway (OK, you need this in DEVEL example, I don't)
> There is HEAD and AC-branch on some package (multiple files). You do merge to
> head and then delete ac-branch. Few days later you want to revert that and...
> huston we have a problem.
:-)
That's the very reason that a few days ago I did `builder -g -r
AC-branch {udev,hal}.spec`. No offence intended, I do appreciate the
effort to make HEAD usable for everyone. I just smell trouble, sincerely
hoping to be wrong.
--
Paweł Sakowski <[EMAIL PROTECTED]>
PLD Linux Distribution
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Sat, Sep 10, 2005 at 00:02:45 +0200, Paweł Sakowski wrote:
> Untrue. rpm uses macros. The way the macros are currently defined uses
> SPECS/SOURCES subdirs. A quick-and-unperfect %(pwd) in the appropriate
> place would make it:
>
> svn co .../foo;cd foo;rpmbuild foo.spec
OK, easily aliased.
> > 5. reverting a commit:
> > cvs:cvs up -r X foo; mv foo{,.tmp}; cvs up -A foo; mv -f
> > foo{.tmp,}; cvs ci foo
>
> Easier:
> cvs up -j X -j HEAD foo;cvs ci foo
> (maybe the other way round... I don't remember the exact -j syntax)
I don't remember too, so mv trick is actually easier;)
--
GoTaR gotar>http://vfmg.sourceforge.net/
http://tccs.sourceforge.net/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Fri, Sep 09, 2005 at 23:28:32 +0200, Arkadiusz Miskiewicz wrote:
> Do you know that here you are not talking about cvs vs svn but about how we
> want to organise repository layout?
We don't. rpmbuild uses flat structure and so I want the repos.
> rpmbuild -bb --define _topdir somewhere
>
> because you would have /packages/gcc/trunk/{SPECS,SOURCES}
You are kidding, aren't you? I'm using rpmbuild a hundred times often
than fetching sources and milion times than reverting commit and you
want me to type these defines?
> Note that you are comparing quite ugly, huge and hardly maintainable builder
> script (1787 lines) with svn. Now please do that with cvs client only without
> additional stuff.
This script EXISTS. Give me a handy tool for svn.
> SPECS/SOURCES to nicer scheme and we should talk about that scheme. With new,
IMHO current is nice.
> > 3. fetching all specs:
> > cvs:cvs up
> > svn:
> > for pkg in `svn ls http://.../packages/`; do
> > do whatever you need
> > done
> >
> > ohhh, it really sucks...
> Again, you seem to think svn == /packages/something layout. These are two
> separate things.
So what? I want to checkout all the specs, I'm not interested in sources
or anything else.
> With the /packages you get some things and also loose some
> things.
That's obvious. Particulary I don't get anything from what you're saying
for now.
> > 4. commiting changes:
> > cvs:cvs ci foo.spec; cd ../SOURCES; cvs ci *
> > svn:svn ci foo
> >
> > hmmm, not so big difference, don't talk about atomic commits anymore.
> > Anyway - if we want this functionality, we could move SOURCES and SPECS
> > into higher level repo directory, so that they would be subdirs.
> Atomic is the key here. You are trying to ignore that which is weird.
I don't get it. Why is:
cvs ci SPECS/foo.spec SOURCES/foo.patch
worse than the same in svn?
> > And now NOT COMMON ones:
> >
> > 5. reverting a commit:
> > cvs:cvs up -r X foo; mv foo{,.tmp}; cvs up -A foo; mv -f
> > foo{.tmp,}; cvs
> > ci foo svn: svn revert foo
> >
> > no difference for me. Not an argument.
> You are talking about _single_ file. Try to revert whioe logical commit of
> for
> example update of gcc from 4.0 to 4.0.1.
Do you want me to write you 4-line script?
> It's single command with svn and tens with cvs.
And we all are doing it every day... just use TAGging when working on
100 files.
> > well, I don't care about names, I asked to do this once or twice.
> You seem to do not care about a lot of important things.
Yeah, I'm evil.
> I remember complaints
> from developers that files where copied by cvsadmin not as fast as developers
> wanted.
Oh my god! Really!?
> > 6. access to deleted TAGS
> > cvs:none
> > svn:is
> >
> > who needs it anyway (OK, you need this in DEVEL example, I don't)
> There is HEAD and AC-branch on some package (multiple files). You do merge to
> head and then delete ac-branch.
We're deleting such branches?
> Few days later you want to revert that and...
...and I have never had such situation.
> 7. work on branches
> cvs: problematic if you want to work on several branches of the same files
> (quite common for me, head + ac-branch); can be somehow workarounded by using
> builder-like script
I'm doing it in separate directories.
echo NAC-branch > CVS/Tag
> svn: easy, separate dirs,
Yeah, separate - SPECS, SPECS-devel, SPECS-foo.
> 8. writting scripts for scm like builder
> cvs: problematic, parsing everything as strings
> svn: great python bindings (for example I have repo where there is
And all clear. I don't like python at all;)
> 9. doing diffs
> cvs: problematic if you want to compare whole packages, easy for individual
Hey, we're not working on sources, but on specs and patches.
> Please think about what could be done better.
If you give me tool for things I'm doing right now (as written), I won't
care about background.
--
GoTaR gotar>http://vfmg.sourceforge.net/
http://tccs.sourceforge.net/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Saturday 10 of September 2005 02:59, Tomasz Pala wrote:
> On Fri, Sep 09, 2005 at 23:28:32 +0200, Arkadiusz Miskiewicz wrote:
> > Do you know that here you are not talking about cvs vs svn but about how
> > we want to organise repository layout?
>
> We don't. rpmbuild uses flat structure and so I want the repos.
I dont care what you want. Your help in developing PLD is marginal.
> > rpmbuild -bb --define _topdir somewhere
> >
> > because you would have /packages/gcc/trunk/{SPECS,SOURCES}
>
> You are kidding, aren't you? I'm using rpmbuild a hundred times often
> than fetching sources and milion times than reverting commit and you
> want me to type these defines?
No, read again. Scripts needs to be written the same way as for cvs. svn it's
not a super-machine-for-doing--exactly-what-pala-wants but simple scm system.
>
> > Note that you are comparing quite ugly, huge and hardly maintainable
> > builder script (1787 lines) with svn. Now please do that with cvs client
> > only without additional stuff.
>
> This script EXISTS. Give me a handy tool for svn.
As I wrote already - it has to be written _before_ anything can happen.
> > SPECS/SOURCES to nicer scheme and we should talk about that scheme. With
> > new,
>
> IMHO current is nice.
It's not because you have no idea which patch belongs (now or in past) to
which spec etc. qboosh is catching many such cases and deletes unused files -
with svn this is as easy as doing ls && less.
> So what? I want to checkout all the specs, I'm not interested in sources
> or anything else.
Use ./builder -f SPECS? Where builder has to be written.
> > > 4. commiting changes:
> > > cvs: cvs ci foo.spec; cd ../SOURCES; cvs ci *
> > > svn: svn ci foo
> > >
> > > hmmm, not so big difference, don't talk about atomic commits anymore.
> > > Anyway - if we want this functionality, we could move SOURCES and SPECS
> > > into higher level repo directory, so that they would be subdirs.
> >
> > Atomic is the key here. You are trying to ignore that which is weird.
>
> I don't get it. Why is:
>
> cvs ci SPECS/foo.spec SOURCES/foo.patch
>
> worse than the same in svn?
If you still don't understand what atomic commits are then talk with you is
pointless.
> > > And now NOT COMMON ones:
> > >
> > > 5. reverting a commit:
> > > cvs: cvs up -r X foo; mv foo{,.tmp}; cvs up -A foo; mv -f foo{.tmp,};
> > > cvs ci foo svn: svn revert foo
> > >
> > > no difference for me. Not an argument.
> >
> > You are talking about _single_ file. Try to revert whioe logical commit
> > of for example update of gcc from 4.0 to 4.0.1.
>
> Do you want me to write you 4-line script?
Yes, please.
> > It's single command with svn and tens with cvs.
> And we all are doing it every day... just use TAGging when working on
> 100 files.
Nice joke.
> > I remember complaints
> > from developers that files where copied by cvsadmin not as fast as
> > developers wanted.
>
> Oh my god! Really!?
Really.
> > > 6. access to deleted TAGS
> > > cvs: none
> > > svn: is
> > >
> > > who needs it anyway (OK, you need this in DEVEL example, I don't)
> >
> > There is HEAD and AC-branch on some package (multiple files). You do
> > merge to head and then delete ac-branch.
>
> We're deleting such branches?
Of course we are. You have no clue what's happening there.
> > Few days later you want to revert that and...
> ...and I have never had such situation.
Because you do (almost) nothing?
> > 8. writting scripts for scm like builder
> > cvs: problematic, parsing everything as strings
> > svn: great python bindings (for example I have repo where there is
>
> And all clear. I don't like python at all;)
There are other bindings. perl, java.
> > 9. doing diffs
> > cvs: problematic if you want to compare whole packages, easy for
> > individual
>
> Hey, we're not working on sources, but on specs and patches.
And so what? For merging rpm from head to ac-branch you need to review spec
and _all_ patches. spec + patches is like sources, no difference.
> > Please think about what could be done better.
>
> If you give me tool for things I'm doing right now (as written), I won't
> care about background.
Ehh, so this whole talk is pointless since such tool NEEDS to be written
first.
--
Arkadiusz MiśkiewiczPLD/Linux Team
http://www.t17.ds.pwr.wroc.pl/~misiek/ http://ftp.pld-linux.org/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Sat, 10 Sep 2005, Arkadiusz Miskiewicz wrote: > And so what? For merging rpm from head to ac-branch you need to review spec > and _all_ patches. spec + patches is like sources, no difference. And svn changes _nothing_ here, I still would have to review all the patches regardless of scm :/ SVN will not suddently solve all problems, it will just change them into other problems. Janek -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Fri, 09 Sep 2005, Arkadiusz Miskiewicz wrote: > svn: see how creating diff between release and branch of kdebase package is: > svn diff svn://anonsvn.kde.org/home/kde/tags/KDE/3.4.2/kdebase \ > svn://anonsvn.kde.org/home/kde/branches/KDE/3.4/kdebase \ > > kdebase-branch.diff > _without_ having anything beside svn client locally Side note about command line - it's what pisses me the most in svn, the requirement to type whole long URLs. I don't need to know them, it's the scm job to remember root dir for a repository/module. With cvs I just do 'cvs up -r TAG file', with svn I have to type a fscking lng, exact, URL, which just hinders and slows the work down. A lot. Janek -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Saturday 10 September 2005 13:48, Jan Rekorajski wrote: > Side note about command line - it's what pisses me the most in svn, the > requirement to type whole long URLs. I don't need to know them, it's the > scm job to remember root dir for a repository/module. > With cvs I just do 'cvs up -r TAG file', with svn I have to type a > fscking lng, exact, URL, which just hinders and slows the work down. > A lot. unless there already exists, write bash-completion code? > Janek -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Saturday 10 of September 2005 12:42, Jan Rekorajski wrote: > On Sat, 10 Sep 2005, Arkadiusz Miskiewicz wrote: > > And so what? For merging rpm from head to ac-branch you need to review > > spec and _all_ patches. spec + patches is like sources, no difference. > > And svn changes _nothing_ here, I still would have to review all the > patches regardless of scm :/ The point is not review itself but getting files/diffs to do that review. You get diff with single svn command with proposed repo scheme while for cvs you need to find out which files are needed, then diff each file. > SVN will not suddently solve all problems, it will just change them into > other problems. The switch is fine when the most annoying problems will go away without bringing new, worse problems. > Janek The switch can't happen without demo/test repo first. Well, I don't think it will (ever) happen - no man resources to do all the stuff (and there are tons of things to be done). -- Arkadiusz MiśkiewiczPLD/Linux Team http://www.t17.ds.pwr.wroc.pl/~misiek/ http://ftp.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Saturday 10 of September 2005 12:48, Jan Rekorajski wrote: > On Fri, 09 Sep 2005, Arkadiusz Miskiewicz wrote: > > svn: see how creating diff between release and branch of kdebase package > > is: svn diff svn://anonsvn.kde.org/home/kde/tags/KDE/3.4.2/kdebase \ > > svn://anonsvn.kde.org/home/kde/branches/KDE/3.4/kdebase \ > > > > > kdebase-branch.diff > > > > _without_ having anything beside svn client locally > > Side note about command line - it's what pisses me the most in svn, the > requirement to type whole long URLs. I don't need to know them, it's the > scm job to remember root dir for a repository/module. svn remembers the urls in the same way as cvs. mkdir /tmp/whatever; cd /tmp/whatever; cvs up -r TAG file won't work. you still need to specify whole -d:pserver:[EMAIL PROTECTED]:/somethingelse > With cvs I just do 'cvs up -r TAG file', with svn I have to type a > fscking lng, exact, URL, which just hinders and slows the work down. > A lot. svn co -N longurl dir once, then cd dir; svn up something It will never be exactly the same as in cvs of course. With cvs it was annoying, too. But not in cvs pld, some of my aliases for example cvse='CVS_RSH=ssh cvs -d:ext:[EMAIL PROTECTED]:/cvsroot/ezmlm-cgi-py' cvspure='CVS_RSH=ssh cvs -d:ext:[EMAIL PROTECTED]:/cvsroot/pureftpd' > Janek -- Arkadiusz MiśkiewiczPLD/Linux Team http://www.t17.ds.pwr.wroc.pl/~misiek/ http://ftp.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Sat, 10 Sep 2005, Arkadiusz Miskiewicz wrote: > On Saturday 10 of September 2005 12:48, Jan Rekorajski wrote: > > On Fri, 09 Sep 2005, Arkadiusz Miskiewicz wrote: > > > svn: see how creating diff between release and branch of kdebase package > > > is: svn diff svn://anonsvn.kde.org/home/kde/tags/KDE/3.4.2/kdebase \ > > > svn://anonsvn.kde.org/home/kde/branches/KDE/3.4/kdebase \ > > > > > > > kdebase-branch.diff > > > > > > _without_ having anything beside svn client locally > > > > Side note about command line - it's what pisses me the most in svn, the > > requirement to type whole long URLs. I don't need to know them, it's the > > scm job to remember root dir for a repository/module. > svn remembers the urls in the same way as cvs. > > mkdir /tmp/whatever; cd /tmp/whatever; cvs up -r TAG file > won't work. you still need to specify whole > -d:pserver:[EMAIL PROTECTED]:/somethingelse I think you didn't get my point. With cvs I do cvs up once and then I have ':pserver:[EMAIL PROTECTED]:/somethingelse' in CVS/Root and I don't have to specify it anymore. With svn every time I want some tag/branch I must specify the whole URL for that tag or branch. Any svn command that has something to do with tag/branch requires URLs. No such requirement with cvs. What's interesting is that svn keeps this info in .svn/ and does not use it. Sick. > > With cvs I just do 'cvs up -r TAG file', with svn I have to type a > > fscking lng, exact, URL, which just hinders and slows the work down. > > A lot. > svn co -N longurl dir once, then > cd dir; svn up something > > It will never be exactly the same as in cvs of course. > > With cvs it was annoying, too. But not in cvs pld, some of my aliases for > example > > cvse='CVS_RSH=ssh cvs > -d:ext:[EMAIL PROTECTED]:/cvsroot/ezmlm-cgi-py' > cvspure='CVS_RSH=ssh cvs > -d:ext:[EMAIL PROTECTED]:/cvsroot/pureftpd' Wouldn't it be easier to do 'cvs login ; cvs co' once? And then you don't need '-d ...' because it saved in CVS/Root. Works for me. Janek -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On Sat, Sep 10, 2005 at 11:31:35 +0200, Arkadiusz Miskiewicz wrote: > I dont care what you want. Your help in developing PLD is marginal. Indeed, thanks to people like you. I'm tired of 'hey, who has broken mysql today?' > No, read again. Scripts needs to be written the same way as for cvs. svn it's [...] > As I wrote already - it has to be written _before_ anything can happen. [...] > Use ./builder -f SPECS? Where builder has to be written. > > > Few days later you want to revert that and... > > ...and I have never had such situation. > Because you do (almost) nothing? Yes. And I'm trying not to fuck up things (and leave for somebody else to care like you've done many times, no offence). > > And all clear. I don't like python at all;) > There are other bindings. perl, java. Ok, perl is good. > Ehh, so this whole talk is pointless since such tool NEEDS to be written > first. Here's my proposal: insert a few packages into SVN, start writing some tools and SHOW us (me) how it works, we'll test it and make decision basing on experience not hipothetical situations. -- GoTaR gotar>http://vfmg.sourceforge.net/ http://tccs.sourceforge.net/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
Jan Rekorajski wrote: > On Sat, 10 Sep 2005, Arkadiusz Miskiewicz wrote: > >>On Saturday 10 of September 2005 12:48, Jan Rekorajski wrote: >> >>>On Fri, 09 Sep 2005, Arkadiusz Miskiewicz wrote: >>> svn: see how creating diff between release and branch of kdebase package is: svn diff svn://anonsvn.kde.org/home/kde/tags/KDE/3.4.2/kdebase \ svn://anonsvn.kde.org/home/kde/branches/KDE/3.4/kdebase \ >kdebase-branch.diff _without_ having anything beside svn client locally >>> >>>Side note about command line - it's what pisses me the most in svn, the >>>requirement to type whole long URLs. I don't need to know them, it's the >>>scm job to remember root dir for a repository/module. >> >>svn remembers the urls in the same way as cvs. >> >>mkdir /tmp/whatever; cd /tmp/whatever; cvs up -r TAG file >>won't work. you still need to specify whole >>-d:pserver:[EMAIL PROTECTED]:/somethingelse > > I think you didn't get my point. With cvs I do cvs up once and then > I have ':pserver:[EMAIL PROTECTED]:/somethingelse' in CVS/Root > and I don't have to specify it anymore. With svn every time I want some > tag/branch I must specify the whole URL for that tag or branch. > Any svn command that has something to do with tag/branch requires URLs. > No such requirement with cvs. > > What's interesting is that svn keeps this info in .svn/ and does not use > it. Sick. If you checkout tags/ and branches/ (probably empty) than you won't need to type the URLs. The URLs are only needed when you want to do server-side cp or mv (which is not possible with CVS at all). -- Regards, Jakub Piotr Cłapa ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
