Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
On Mar 25, 2004, at 5:05, Jan Wieck wrote: The difference here is that instead of submitting a patch for review, which is then frozen, the branch owner can (and that means some will, no matter what your intentions are) keep modifying the branch during the review process, other than just keeping it in sync with conflicting changes to the trunk. How do you plan to prevent that? You do both. Changesets are immutable. A patch cannot be modified. However, new patches can be added for tracking changes to the tree. You can review the original diff, and you can review how it's tracked head-of-line changes independently. You can take the original diff and manually wedge it in if you want, or you can see how the latest progress differs before submission. -- Dustin Sallings ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
On Mar 25, 2004, at 1:21, Neil Conway wrote: I think the lack of good Win32 support (unless rectified before the release of 7.5) is a pretty major problem with Arch -- that alone might be sufficient to prevent us from adopting it. I don't do Windows, but my understanding is that tla is as well supported on Windows as postgres is. The design is fundamentally easy enough that a Windows user who cares could probably make a more suitable port for Windows than the UNIX guys are interested in making. I've seen such discussions on the list. -- Dustin Sallings ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
On Mar 25, 2004, at 9:22, Magnus Naeslund(t) wrote: You can use distributed revision control systems as centralized systems, but not vice-versa. Not true, the other way around exists, that is what svk does. From its description, svk sounds like a completely different system: ``svk is a decentralized version control system written in Perl. It uses the subversion filesystem but provides some other powerful features.'' I.e. it seems to have a CVS vs. RCS relationship. It would be unfair to call CVS RCS. -- Dustin Sallings ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] linked list rewrite
On Mar 23, 2004, at 11:45, Tom Lane wrote: AFAICS, though, CVS is not broken for our needs. I don't see an adequate reason to change. Yes, of course. I guess my point is that if you're going to move away from CVS, please don't just jump to ``slightly better CVS.'' I'm looking forward to a world with more open source projects in distributed revision control. The ones I'm tracking and doing personal branches against (vim, tla, a couple of other small projects) are liberating. Branching a tree I didn't expect to even have to edit while on an airplane recently was a very pleasant experience. Actually, being able to branch without thinking about the horrible consequences of CVS has been wonderful in general. As long as CVS works for you, though, you should continue to use it. -- SPY My girlfriend asked me which one I like better. pub 1024/3CAE01D5 1994/11/03 Dustin Sallings [EMAIL PROTECTED] |Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE L___ I hope the answer won't upset her. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
On Mar 24, 2004, at 7:29, Frank Wiles wrote: [cool feature list] Arch has all of that except for the checking out part of a directory thing (would you really just check out the backend, submit a change, and not build and test it?). Additionally: * Repositories can be easily replicated so checkouts don't have to cross slow networks. I replicate every repository I work with to every machine I use. This is not only my backup strategy, but it makes checkouts faster. * You can work completely offline. In addition to being able to diff, undo changes, redo changes, etc... while offline, you can completely branch a project do multiple commits, and merge them back into the main archive when your plane lands. * Branches are not only cheap, but can easily cross repository boundaries. Any given user can create a branch from the head-of-line tree and maintain changes, and the head-of-line maintainers can pull those changes back in. * Its storage is immutable. It never modifies a file so it does not provide any possibility for corruption. This is also what makes replication so trivial. * Changesets have cryptographic checksums and may be cryptographically signed. Checkouts are authenticated against both of these. * Repositories can be accessed via a wide variety of means. Most of mine are local file, WebDAV, or SFTP. I allow read-only access via plain HTTP for anyone who wants to check out one of my projects. * Files can be tracked in a nearly (or completely) automatic fashion. Depending on project configuration, you can avoid having to interact with the revision control system other than writing changelogs and submitting patches. You an also use CVS-style tracking (manual adds and deletes (plus moves)) if you're more comfortable that way. * The design is way, way more simple and transparent, there are far fewer requirements. At least for me, this translates to a higher confidence that my stuff will always be available. The advantage I see to Subversion is that it's designed to be a better CVS. Since many people are comfortable with CVS and that style of centralized development, it may feel a little more natural for new converts. I feel that that's because it doesn't seem to take you very far. -- Dustin Sallings ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
On Mar 24, 2004, at 13:22, David Garamond wrote: From what I read here and there, BitKeeper excels primarily in merging (good merging is apparently a very complex and hard problem) and GUI stuffs. There's not a lot of GUI in arch, but star-merge is fairly incredible. This is how tla (the main arch implementation) itself is developed. Lots of branches in lots of archives by lots of people. Unfortunately, I have never and will never use Bitkeeper unless someone buys me a license for some reason. The distributed model seems like the only way to go for the open source development of the future. Not necessarily. For small to medium projects, a centralized model might work better. I make use of the distributed nature of arch in my personal projects with no other developers. Offline work is just a branch in another archive that gets merged in later. Arch supports a centralized model as well as anything else, and I've got a big centralized set of archives, but I don't always have good connectivity to the master. This is where the distributed model wins. A server/network/whatever outage does not have the opportunity to slow me down. In the worst case, a long outage causes my branch to drift a little further from head of line than it normally would. -- Dustin Sallings ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
On Mar 24, 2004, at 18:22, Magnus Naeslund(t) wrote: The new buzz is distributed versioning systems these days, but i question if that is called for in the vast majority of projects out there. You can use distributed revision control systems as centralized systems, but not vice-versa. But ofcourse arch has alot of features that are extremly cool, the reason why i didn't evaluate it further was that it didn't work on windows well, the fixed weird branching/version naming and the complexity of learning for our developers since they already use cvs. Depends on how you set it up. In the recommended ``tagline'' method, you don't have to tell the revision control system when you add, remove, or move files (for the most part, binary files are not suitable for tagline). All you have to do is commit and type a message. Subversions strength is it's percieved simplicity, and archs strength is it's complexity. It is subversion's complexity that drove me away from it, in fact. Arch is incredibly simple all the way through. It sounds like it must be complex to be able to do all of the things people do with it, but it's most assuredly not. The requirements are few and basic (diff, patch, and tar). The most common stuff is at least as simple as CVS (commit, update and in explicit mode, add, rm, and mv), and the advanced stuff is just as easy as the simple stuff (star-merge, tag (branching), etc...). As far as understanding the simplicity of arch (if you wanted to understand the problems it solves and implement it yourself), a really good presentation was posted today to the arch list that sums it up quickly and concisely. It's hard to go through that and not think, ``I could write this.'' http://web.verbum.org/tla/grokking-arch/grokking-arch.html -- SPY My girlfriend asked me which one I like better. pub 1024/3CAE01D5 1994/11/03 Dustin Sallings [EMAIL PROTECTED] |Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE L___ I hope the answer won't upset her. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
On Mar 24, 2004, at 20:29, Tom Lane wrote: Not here. You want me to trust some bit of code (with absolutely zero understanding of the source text it's hacking on) to figure out how to resolve conflicting patches? That sounds like a recipe for big-time unhappiness. The idea is that it's the responsibility of the branch owner to keep it up-to-date. For example, I've got a branch of tla (an arch implementation) I made soon after I started using it in order to add a command I wanted and refactor a bit of the insides. Over time, a lot of stuff has changed, but I still want my stuff to work, so as I update my branch against head of line, I make minor changes to it as things go. The difference is that instead of having a patch sitting in a queue somewhere suffering from bit-rot, you've got a pointer to a branch that you can merge when you get around to it. You can still view it as a diff if you want, but the diff you get six months after the original submission may be quite a bit different from what you would've got at the beginning if a lot of the code around it has changed. It's definitely not a magic tool that makes bad code good and conflicting patches happy. It solves other problems, though. Many of the problems you don't realize you have until you go back to something else and try to do something simple like undo all of the changes you've made since your last checkin. -- SPY My girlfriend asked me which one I like better. pub 1024/3CAE01D5 1994/11/03 Dustin Sallings [EMAIL PROTECTED] |Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE L___ I hope the answer won't upset her. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] linked list rewrite
On Mar 23, 2004, at 8:39, Sailesh Krishnamurthy wrote: Which brings me to another question .. has anybody considered using subversion instead of CVS ? My guess would be only people who haven't used arch. :) Seriously, though. Decentralized, disconnected revision control is a lot nicer to work with in open source projects...especially larger ones with more developers in more locations. -- Dustin Sallings ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [ADMIN] how to alter sequence.
Around 20:41 on Dec 4, 2002, Hannu Krosing said:
What's wrong with this:
dustin=# create sequence test_seq;
CREATE SEQUENCE
dustin=# select nextval('test_seq');
nextval
-
1
(1 row)
dustin=# select setval('test_seq', );
setval
(1 row)
dustin=# select nextval('test_seq');
nextval
-
1
(1 row)
# Oliver Elphick kirjutas K, 04.12.2002 kell 19:06:
# On Wed, 2002-12-04 at 12:29, raja kumar thatte wrote:
# Hai friends,
# I have a sequence called raj_seq with max value 3000.
# ...
# now i wanted to increase the max value of the raj_seq
# to 999.
# How to do this change?
# If i drop and recreate the raj_seq, then i have to
# recreate the table and all triggers working on that
# table.But it is not an acceptable solution.
# So with out droping raj_seq , how do I solve this
# problem.
#
# Unfortunately there doesn't seem to be any easy way to do this. There
# is no ALTER SEQUENCE command and you can't use UPDATE on a sequence.
#
# Hackers: Could this be a TODO item for 7.4?
#
# This seems to work - as an example why we need the TODO ;)
#
# hannu=# update seq set max_value = 99;
# ERROR: You can't change sequence relation seq
# hannu=# update pg_class set relkind = 'r' where relname = 'seq';
# UPDATE 1
# hannu=# update seq set max_value = 99;
# UPDATE 1
# hannu=# update pg_class set relkind = 'S' where relname = 'seq';
# UPDATE 1
# hannu=# select * from seq;
# sequence_name | last_value | increment_by | max_value | min_value |
# cache_value | log_cnt | is_cycled | is_called
#
---++--+---+---+-+-+---+---
# seq | 1 |1 |99 | 1
# | 1 | 1 | f | f
# (1 row)
#
# I can't really recommend it, because it may (or may not ;) have some
# unwanted behaviours as well;
#
#
#
# The easiest way to do this at present is probably to dump the database,
# edit the dump to change the sequence max_value and then recreate the
# database from the edited dump. I presume you used CREATE SEQUENCE in
# order to get such a low max_value. If it were created from a SERIAL
# datatype, you would also have to edit the table definition to use a
# pre-created sequence. There is no means of specifying a max_value using
# SERIAL.
# --
# Hannu Krosing [EMAIL PROTECTED]
#
# ---(end of broadcast)---
# TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
#
#
--
SPY My girlfriend asked me which one I like better.
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings [EMAIL PROTECTED]
|Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L___ I hope the answer won't upset her.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [ADMIN] how to alter sequence.
Around 12:44 on Dec 4, 2002, Joel Burton said: # The thread here is about how to raise the *max* value for the sequence, # not how to set the current value higher. The sequence in question was # created with a too-low maximum value (see help on CREATE SEQUENCE for # options); the user now wants to raise it. Ahh, OK. Seemed too obvious. :) -- SPY My girlfriend asked me which one I like better. pub 1024/3CAE01D5 1994/11/03 Dustin Sallings [EMAIL PROTECTED] |Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE L___ I hope the answer won't upset her. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
