Re: [Python-Dev] Looking for VCS usage scenarios
Stephen J. Turnbull schrieb: > Tres Seaver writes: > > > svn doesn't have any true tags, AFAIK: everything is a branch. > > Yow! I couldn't have imagined that would be true. And didn't It's not exactly true either. svn doesn't have either tags or branches, it has only a single (directory) tree per repository, of which individual subdirectories can be checked out individually. This is the root of the usual first step in creating a SVN repo: make "branches", "trunk" and "tags" subdirs. In this context it is not surprising that there is no separate branch or tag concept. I think the reason is that CVS *had* branches and tags as separate concepts and it must have been relatively painful to use them. cheers, Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
Stephen J. Turnbull wrote: > I don't know about svn; I find it pretty painful to use for anything > but sequential tasking (update ... hack ... commit ... repeat). But > if you look at http://git.kernel.org/, you'll see a thicket of repos, > each of which probably contains a few to a few hundred[1] branches > (mostly merged to repo mainline or abandoned, of course). If it isn't already there, suspending work on something to work on something else would make a very nice scenario to cover, as it is something even the core devs sometimes have to deal with. I'd expect any DVCS to be able to handily beat what I currently do with SVN: - # hack on first task - svn diff > _patches/first_task.diff - svn revert -R . - svn update - # hack on second task - svn commit OR svn diff > _patches/second_task.diff (depending on whether or not I want it reviewed by someone else before committing it) - svn revert -R . - patch -p0 < _patches/first_task.diff - # back to hacking on first task Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
> > >* Will a DVCS allow simpler operation as if we are still using a > > > centralized system like CVS or Subversion? > > Yes and no. There is nothing to prevent a formal workflow like that > in CVS/Subversion. However, the separation of "commit" into "record > && push to authoritative" leaves open the possibility of annoying > glitches until you get used to it, and even then it's easy to forget > to push or to forget that you've committed not-for-pushing stuff, etc, > etc. In practice it is probably simpler to use a dVCS-specialized > workflow like "record && push to candidate". Bazaar offers the same semantic if you want to use it. In practice, when you use "bzr checkout" to get a branch, it becomes bound to the remote branch. When you commit to a local bound branch, the change is automatically pushed to the server, including the needed locking semantics, so the workflow is pretty much the same as if it were a Subversion checkout (hence the command name). Branches can be freely bound and unbound without effort, if desired. In the team I work on we've been using this for a while for the "authoritative" branches. So it's a distributed workflow otherwise, but at the end of the life cycle of a branch, we merge and commit to a bound branch pretty much like committing a change to Subversion. -- Gustavo Niemeyer http://niemeyer.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Georg Brandl wrote: > Stephen J. Turnbull schrieb: >> Tres Seaver writes: >> >> > svn doesn't have any true tags, AFAIK: everything is a branch. >> >> Yow! I couldn't have imagined that would be true. And didn't > > It's not exactly true either. svn doesn't have either tags or branches, > it has only a single (directory) tree per repository, of which individual > subdirectories can be checked out individually. This is the root of the > usual first step in creating a SVN repo: make "branches", "trunk" and > "tags" subdirs. The SVN docs use the term "branch" for this concept: http://svnbook.red-bean.com/en/1.0/ch04.html#svn-ch-4-sect-1 And they document that tags are really branches: http://svnbook.red-bean.com/en/1.0/ch04s06.html If you have some other definition for "branch", that's fine, but you will need to outline how that differs from SVN's use of the term, given that SVN is the reference model for Python development at ths moment. > In this context it is not surprising that there is no separate branch or > tag concept. I think the reason is that CVS *had* branches and tags as > separate concepts and it must have been relatively painful to use them. At the conceptual level, a tag would be the equivalent of a "symlink", rather than a copy: if they existed in SVN, tags would be pointers to another branch, frozen in at a given revision. The SVN team denies the utility of tags, which doesn't change the fact that other folks like and use them effectively in other systems. Any issues related to the implementation of tags and branches in CVS are irrelevant to the usefulness of tags: I have found them very useful in many other VCSes (ClearCase, Perforce, etc.), and find their deliberate omission from SVN to be a misfeature. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJEuhH+gerLs4ltQ4RAuFWAKCRg7LnBeUGJVYXUwQ9eRsq36bz8QCgx7fv 04UtndVdgiGUQOp7UAUTE9I= =SvBQ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DVCS PEP update
Brett Cannon python.org> writes: > So my first choice for Mercurial fell through. If you would like to > represent Mercurial, let me know. I can represent Mercurial, though it may be (more?) helpful if some of the Mercurial-using python-dev regulars can occasionally step in. Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DVCS PEP update
On Thu, Nov 6, 2008 at 8:04 AM, Dirkjan Ochtman <[EMAIL PROTECTED]> wrote: > I can represent Mercurial, though it may be (more?) helpful if some of the > Mercurial-using python-dev regulars can occasionally step in. I like mercurial, so I'll do this if I see something, but I don't use it for anything that heavy-duty, so I don't expect to be able to say anything very convincing, or, I suppose, intelligent. -- Cheers, Leif ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DVCS PEP update
2008/11/6 Dirkjan Ochtman <[EMAIL PROTECTED]>: > Brett Cannon python.org> writes: >> So my first choice for Mercurial fell through. If you would like to >> represent Mercurial, let me know. > > I can represent Mercurial, though it may be (more?) helpful if some of the > Mercurial-using python-dev regulars can occasionally step in. I'll help out where I can. But my Mercurial usage is pretty basic (linear history on personal projects, mainly) so I'll avoid the complex questions :-) Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DVCS PEP update
Brett Cannon wrote: I have emailed some people who have shown allegiance to a specific DVCS to seeif they are willing to fill in the usage scenarios for me along with converting the dev FAQ so that we all have a clear way to learn how to use the things. If any of the people I emailed turn down being the leader fo ra specific DVCS I will email here looking for volunteers. Hey Brett! I'm missing a few points in your use case list: * Does the DVCS handle merges over file reneames, directory renames and file moves to another directory? * Are there any graphical interfaces to the DVCS? Tortoise svn is a killer application for Windows users. * How hard is it to install the DVCS for a user few or no CLI experience? Are there installers for the most common systems (Mac, Windows, Debian and RPM based distros)? Do the installers and packages require uncommon extensions, 3rd party tools or admin privileges? Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
On Thu, Nov 6, 2008 at 8:35 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > I'd expect any DVCS to be able to handily beat what I currently do with SVN: Yes, it does. I have extensive experience in bzr, less in git (but vastly prefer it since I have been using it), and both are relatively good for this kind of scenario. In git, you can for example create a new branch (often called feature branch, also technically, it is just a branch): git co -b newbranch1 # Create new branch1 and go into it # hack, commit git cb -n newbranch2 # create new branch2 # More hacking git co newbranch1 # go back to branch 1 It can be more elaborate than that, using stash to set uncommitted changes, rebase to update your changes on the top of the last revision of the main branch you are tracking (trunk in svn parlance). Bzr is similar, except that it is more commands to switch from branch to branch; bzr has the shelve command to do as git stash. You can also use loom, but I never used them extensively (loom are a plugin extension of bzr, and not well documented; I could not understand it, at least, although I did not try too hard). cheers, David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 5, 2008, at 8:36 PM, Stephen J. Turnbull wrote: I disagree. This doesn't scale to Python size. For distributed VC to work, somebody has to maintain a repo 24x7. Python has to do this for the trunk; the additional burden for contributed patches is not great. There is no real advantage to having contributors do so, too.[3] Integrators and interested third parties also must keep track of contributor's repo URLs. (Cf. Skip's question about discovering repos.) Not happy stuff. There's an interesting automation available when hosting branches on Launchpad and using a patch queue manager (PQM in particular). I believe this is not quite deployed so I might be speaking out of class, and it's unlikely that Python would do anything but self-host its branches (though this doesn't necessarily prevent the following). Still I will describe this so you see the possibilities. Launchpad has something call "merge proposals". When a branch is ready, the original developer creates a merge proposal which is basically a request for review. The dev can ask for a specific reviewer (e.g. barry for the email package), or he can ask anyone on the team for a review. LP doesn't impose a specific workflow, so some projects require 2 or more reviews for any piece of code, others maybe 1 review, etc. Let's say I review Stephen's branch to fix a bug in the email package. I request some changes, Stephen makes them, and now the branch looks great. I can approve the branch and now neither Stephen nor I need to do anything in order to get that branch pushed to the mainline. This works under the covers as follows: when approved, the branch details get added to a queue managed by Launchpad. Python.org would run a PQM that watches this queue. Python's PQM just picks branches off the top, one by one, and it tries to land them. If any conflicts arise or tests fail, the branch doesn't merge. Otherwise, it lands and all the appropriate metadata about the branch (and its associated bug) gets updated automatically. This is a nice model for several reasons. It's the bot's responsibility to do the grunt work of merging, landing, and pushing new branches to the mainline. Humans only care about developing the code and reviewing the results. Also, this aligns with something I've been very interested in from a release manager's POV: I'd like the mainline branches to always be in a releasable state. We can now define that releasable state to be "whatever adheres to the bot's landing rules". I'm skeptical Python would ever adopt this workflow, if only because there is technical work that would have to be done (i.e. we'd have to run the bot). Still, I wanted to explain this so that you could get a sense of what's possible. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSRMNjnEjvBPtnXfVAQJHXwP/T6WbEIvWC8OJh8i4UnmHvgj8hbT5tbED 2sQRBHNxrBavwhvENUTAM0n4a8j+jSwof8PszflRbiNLVANYKJ1wWHfevkkPcwL7 mzcgtZqpkijWdJoGOeif04LcjuiYopSSEtPLRC9QdDygwlZmhhvbPFVQ2xvtc6C/ 4DO12JDPICA= =Zn9N -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 5, 2008, at 8:36 PM, Stephen J. Turnbull wrote: You need not feel that way. It's not you---the flexibility of dVCS means that until the Powers That Be promulgate a Workflow, this will be ambiguous. You're absolutely right. Adopting a dvcs opens up a much larger world of possible workflows and best practices, both for an individual and for a project. It's a case of too much choice, so I feel strongly that Python should adopt and explain exactly one preferred workflow that will work for most people and use cases. People can still experiment and find alternatives if they want. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSRMRb3EjvBPtnXfVAQJU0AQAugEbLciCd2EIzqPrPOmWykoK7+u1fCAh yLnc3aFeserk50WwYkfovZDZESNs8F8ADZ2CIVGK+5AWW+MC17YAx2P4M0gUEeLY ulTQmrpLuRZHVpD6vqoM9hnI/vvsLwTqcYgqB1lfSLdSZ8RnJTnUPQ7UY7Eq7kfS gmxDhUqYKVg= =T9CJ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 6, 2008, at 6:35 AM, Nick Coghlan wrote: If it isn't already there, suspending work on something to work on something else would make a very nice scenario to cover, as it is something even the core devs sometimes have to deal with. Indeed. as a release manager, I have to manage several branches in parallel. Several are for patches I'm looking at for release blockers, one perhaps for the PEP 101 administrivia, perhaps another pristine one as a baseline, not to mention several I'd have for my own bugs and features. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSRMWtnEjvBPtnXfVAQK1iwP+NShDlAWqvgTh9vO5XbCOSCsC4DXy2KGm eMpG6dBAdbSy4skV0fR9FW1x5b/HrQU2M8y/9LTq4G67DQdkCTzKbJHgW8QaNtG1 BeAhUOaf2URzLlSezbBhrkFxWL45r3bx175eTsKvMhwpxzjSTxCLseT/eaROYlAW P8btKM8Q9xI= =Mrl4 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
Tres Seaver schrieb: > Georg Brandl wrote: >> Stephen J. Turnbull schrieb: >>> Tres Seaver writes: >>> >>> > svn doesn't have any true tags, AFAIK: everything is a branch. >>> >>> Yow! I couldn't have imagined that would be true. And didn't > >> It's not exactly true either. svn doesn't have either tags or branches, >> it has only a single (directory) tree per repository, of which individual >> subdirectories can be checked out individually. This is the root of the >> usual first step in creating a SVN repo: make "branches", "trunk" and >> "tags" subdirs. > > The SVN docs use the term "branch" for this concept: > > http://svnbook.red-bean.com/en/1.0/ch04.html#svn-ch-4-sect-1 > > And they document that tags are really branches: > > http://svnbook.red-bean.com/en/1.0/ch04s06.html Quoting from that page: """ In Subversion, there's no difference between a tag and a branch. Both are just ordinary directories that are created by copying. """ But you're right, it's a question of definitions. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DVCS PEP update
On Thu, Nov 6, 2008 at 06:23, Christian Heimes <[EMAIL PROTECTED]> wrote: > Brett Cannon wrote: >> >> I have emailed some people who have shown allegiance to a specific >> DVCS to seeif they are willing to fill in the usage scenarios for me >> along with converting the dev FAQ so that we all have a clear way to >> learn how to use the things. If any of the people I emailed turn down >> being the leader fo ra specific DVCS I will email here looking for >> volunteers. > > Hey Brett! > > I'm missing a few points in your use case list: > > * Does the DVCS handle merges over file reneames, directory renames > and file moves to another directory? > I consider that a perk feature. > * Are there any graphical interfaces to the DVCS? Tortoise svn is > a killer application for Windows users. > Covered in the OS/Tools section. > * How hard is it to install the DVCS for a user few or no CLI > experience? Are there installers for the most common systems > (Mac, Windows, Debian and RPM based distros)? Do the installers > and packages require uncommon extensions, 3rd party tools or > admin privileges? Also in the OS/Tools section. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DVCS PEP update
On Thu, Nov 6, 2008 at 05:04, Dirkjan Ochtman <[EMAIL PROTECTED]> wrote: > Brett Cannon python.org> writes: >> So my first choice for Mercurial fell through. If you would like to >> represent Mercurial, let me know. > > I can represent Mercurial, though it may be (more?) helpful if some of the > Mercurial-using python-dev regulars can occasionally step in. > I just gave the position, although thanks for offering! If people want to help, here are the people covering the DVCSs, so contact them: Bazaar: Barry Warsaw git: Stephen Turnbull Mercurial: Alexandre Vasalotti These people are going to fill in the scenarios for their respective DVCS and also rewrite the dev FAQ for their DVCS so we have the basic commands documented in a common format. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DVCS PEP update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 6, 2008, at 5:43 PM, Brett Cannon wrote: On Thu, Nov 6, 2008 at 06:23, Christian Heimes <[EMAIL PROTECTED]> wrote: Brett Cannon wrote: I have emailed some people who have shown allegiance to a specific DVCS to seeif they are willing to fill in the usage scenarios for me along with converting the dev FAQ so that we all have a clear way to learn how to use the things. If any of the people I emailed turn down being the leader fo ra specific DVCS I will email here looking for volunteers. Hey Brett! I'm missing a few points in your use case list: * Does the DVCS handle merges over file reneames, directory renames and file moves to another directory? I consider that a perk feature. OTOH, the lack of this is one of the things that piss me of most about subversion. It's really nice when you're in charge of your tool rather than the other way 'round! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSRN1PHEjvBPtnXfVAQKULQP9GDRrT76LCZpVRFNCOP6K6CvVGIvtd9I7 ryPk1RFYTqIduEC3FLvhQh0xjxT2HGo/99m0EZZbM4ZxMbhwvM4Sw8ppkcCFwtig aOcHviDr0SNK6DU3L36/zMPN/Wnap3ltF09nqWYcjcbBdR94oae1K7SF7nkPCSn/ oIb2a9ShBAE= =WnB/ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DVCS PEP update
On Thu, Nov 6, 2008 at 14:52, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Nov 6, 2008, at 5:43 PM, Brett Cannon wrote: > >> On Thu, Nov 6, 2008 at 06:23, Christian Heimes <[EMAIL PROTECTED]> wrote: >>> >>> Brett Cannon wrote: I have emailed some people who have shown allegiance to a specific DVCS to seeif they are willing to fill in the usage scenarios for me along with converting the dev FAQ so that we all have a clear way to learn how to use the things. If any of the people I emailed turn down being the leader fo ra specific DVCS I will email here looking for volunteers. >>> >>> Hey Brett! >>> >>> I'm missing a few points in your use case list: >>> >>> * Does the DVCS handle merges over file reneames, directory renames >>> and file moves to another directory? >>> >> >> I consider that a perk feature. > > OTOH, the lack of this is one of the things that piss me of most about > subversion. It's really nice when you're in charge of your tool rather than > the other way 'round! I'm not saying it wouldn't be very nice to have, just I am as of this moment not going to toss a tool out the door because it doesn't do it better than svn. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
Barry Warsaw wrote: > On Nov 5, 2008, at 8:36 PM, Stephen J. Turnbull wrote: > >> You need not feel that way. It's not you---the flexibility of dVCS >> means that until the Powers That Be promulgate a Workflow, this will >> be ambiguous. > > You're absolutely right. Adopting a dvcs opens up a much larger world > of possible workflows and best practices, both for an individual and for > a project. It's a case of too much choice, so I feel strongly that > Python should adopt and explain exactly one preferred workflow that will > work for most people and use cases. People can still experiment and > find alternatives if they want. This is an area where I think the initial DVCS PEP shouldn't be too ambitious, and focus mainly on the improvements to things we currently do with Subversion and Roundup: - individuals suspending work on one task (e.g. a new feature) to switch to something else (e.g. fixing a bug) (current workflow is multiple checkouts or dumping your first task in a patch file, reverting, working on the second task, dumping or committing it, then patching back to the first task) - backporting and forward porting patches between 3.x/3.x-1/2.y/2.y-1 (current workflow based on svnmerge) - developing and maintaining patches - reviewing patches - collaboration amongst multiple developers on complex patches (current workflow is either forking the standard library and creating a project in the sandbox or somewhere else like Google Code, or else posting and downloading a series of patches on the tracker, or, if all developers involved have SVN access, creating a SVN branch and maintaining it with SVN merge) There's a lot of room for improvement just in those areas, even before we start getting into the potential alternate workflows that a DVCS may enable. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
On Thu, Nov 6, 2008 at 16:47, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Barry Warsaw wrote: >> On Nov 5, 2008, at 8:36 PM, Stephen J. Turnbull wrote: >> >>> You need not feel that way. It's not you---the flexibility of dVCS >>> means that until the Powers That Be promulgate a Workflow, this will >>> be ambiguous. >> >> You're absolutely right. Adopting a dvcs opens up a much larger world >> of possible workflows and best practices, both for an individual and for >> a project. It's a case of too much choice, so I feel strongly that >> Python should adopt and explain exactly one preferred workflow that will >> work for most people and use cases. People can still experiment and >> find alternatives if they want. > > This is an area where I think the initial DVCS PEP shouldn't be too > ambitious, and focus mainly on the improvements to things we currently > do with Subversion and Roundup: Exactly. This is why I asked for only known scenarios we all run into and every one of them has an example svn way of doing it. > - individuals suspending work on one task (e.g. a new feature) to switch > to something else (e.g. fixing a bug) (current workflow is multiple > checkouts or dumping your first task in a patch file, reverting, working > on the second task, dumping or committing it, then patching back to the > first task) Sort of covered. > - backporting and forward porting patches between 3.x/3.x-1/2.y/2.y-1 > (current workflow based on svnmerge) Covered. > - developing and maintaining patches Covered. > - reviewing patches Covered. > - collaboration amongst multiple developers on complex patches (current > workflow is either forking the standard library and creating a project > in the sandbox or somewhere else like Google Code, or else posting and > downloading a series of patches on the tracker, or, if all developers > involved have SVN access, creating a SVN branch and maintaining it with > SVN merge) > Covered. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
Nick Coghlan writes: > If it isn't already there, suspending work on something to work on > something else would make a very nice scenario to cover, as it is > something even the core devs sometimes have to deal with. > > I'd expect any DVCS to be able to handily beat what I currently do > with SVN: Sure, but that's just you. AIUI the "quilt" tool that kernel people use simply automates exactly that process for you in svn or any other VCS. (I don't use quilts myself.) The various DVCSes also have specialized tools for managing patches. Darcs is patch-oriented from the get-go, ditto Arch. Bazaar has "looms", Mercurial has "queues". The advantage of looms and queues is that the patches are managed with the VCS; I don't recall whether there's a way to do that with quilts, but I presume so. However, I suspect if you're expecting to do this more efficiently in a DVCS, you'll be disappointed. I'll make this scenario concrete in the PEP (for git), but I'd say that the "operation count" would be perhaps higher for me, using git as I like to, than in your scenario. Of course they would be VCS operations, not using patch and diff. What doing it in a DVCS provides is (1) a VCS record of what you did, (2) which can easily be published, and (3) the option of using the VCS to merge the two tasks later. In other words, *D*VCS is about keeping and (optionally) communicating *local* history, not about reducing the number of VC-related operations you do. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DVCS PEP update
Brett Cannon writes: > I consider that a perk feature. Let's not judge which features are perks or essential quite yet. (If the number of features/scenarios/whatnot becomes a burden on you, then you must triage them, of course.) But a lot of people will not know what the features are unless they go in the PEP. Eg, I've never actually encountered the merge-across-rename issue in the wild, for example. A scenario where I could actually try it for myself would be educational, as many people I respect swear by it. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
Stephen J. Turnbull wrote: > In other words, *D*VCS is about keeping and (optionally) communicating > *local* history, not about reducing the number of VC-related operations > you do. The bit I left out where it can get painful is when the patch call to go back to the first task fails due to changes picked up in the "svn update" before working on the second task. Even if the basic flow isn't any simpler (suspend original task, start new task, finish new task, go back to original task), a bit of assistance with that last step (when necessary) wouldn't go astray at all :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
Brett Cannon wrote: > I have started the DVCS PEP which can be seen at > http://docs.google.com/Doc?id=dg7fctr4_40dvjkdg64 . Not much is there > beyond the rationale, usage scenarios I plan to use, and what other > sections I plan to write. > Brett: Would you care to get a PEP number allocated to this draft document? I think it's likely that it will eventually be published, and I'd like a number to use in reference to it if possible, please. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RELEASED Python 3.0rc2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Python development team and the Python community, I am happy to announce the second release candidate for Python 3.0. This is a release candidate, so while it is not suitable for production environments, we strongly encourage you to download and test this release on your software. We expect only critical bugs to be fixed between now and the final release, currently planned for 03- Dec-2008. If you find things broken or incorrect, please submit bug reports at http://bugs.python.org For more information and downloadable distributions, see the Python 3.0 website: http://www.python.org/download/releases/3.0/ See PEP 361 for release schedule details: http://www.python.org/dev/peps/pep-0361/ Enjoy, - -Barry Barry Warsaw [EMAIL PROTECTED] Python 2.6/3.0 Release Manager (on behalf of the entire python-dev team) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSRO7wHEjvBPtnXfVAQIYrQP+Lynpa/p7VMY/YxJyjxiBI0bvOATPIKbE jqu9ZFwXlO19+G4bFiAoYviY5UFYPm3TpbMoso2qNoJsJFLSt4d+AycWWcaXKd08 vpifsxVoWvdLCLZtT7ioMBJh/juu+Pchf2o2l+PHm5aWlLvq/24uu8YKbpSKKbr9 K4gB4ecYd3A= =3UPl -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
