@qping maven配合jenkins估计也解决不了你的问题。
我觉得你需要的是一个程序（Ant？Java？Python？）来帮你处理编译后文件的更新问题，大致流程如下：
1、下载和解压目标WAR文件到某个文件夹，这个WAR文件也就是你已经发布到产品服务器上的那个，本质都是zip格式，你懂的
2、查找文件更新：给定一个日期（上次发布的日期？），通过该日期比对源文件的最后更新日期（SVN？本地？），决定是否将该源文件对应的class文件或jsp、js等复制到目标WAR文件夹（假定已经完成编译和其他资源处理）
3、重新压缩WAR文件夹为WAR文件
4、你最好还是基于Branch来，否则在Trunk中有些不必要的文件更新也会纳入进来

—————————————————————分割线——————————————————
说回Maven+Jenkins，我理解你们的处境，别说1G，就算是几十兆的包我都容忍不了，呵呵。
我采取的办法是在生产环境（不一定是服务器，可以是自己的机器或者客户方提供的部署用的机器），使用楼上提到的Maven+Jenkins（当时还叫Hudson），SVN不在生产环境本地都没有关系，只要能联网更新，进行编译、打包，最终的war包要么自动发布上去，要么手工ftp上去，要么U盘copy上去…… 第一次会比较慢，因为要更新所有的源代码并编译，还要下载jar包…… 当然，你可以预先把一个本地的Maven Repository复制到Jenkins服务器上！

总之，不要人工去更新那些war包。

如果你们没有用Maven，用Ant也是可以的，如果你们连Ant都没有用，那就从Maven开始重构吧！

不太明白这个增量包是个什么东东？ 一堆更新了的java class？jsp？

但是SVN是有branch特性的。一般的做法是：基于当前的Trunk版本，可以为将来某天发布、具备某些特性、修复某些bug创建一个branch（其实就是另一个代码库），程序员对这个branch的代码进行更新，测试人员也基于这个branch进行测试。达到要求后，使用branch中的代码进行编译、全新发布；发布成功，将branch中的变更merge回Trunk，Trunk继续成为下一个branch的基线代码库。 merge这个动作都是基于源代码的，而且都要求哪个程序员改动的，哪个就负责merge回Trunk库，遇到多个程序员修改同一部分代码，要求他们内部协调，一般都不会有太大的代码冲突。

如果你的增量包就是我理解的那样，的确工作量大而且容易出错，配置管理形同虚设！请牢记：配置管理应该主要基于源代码（不是绝对，但应该是绝大多数），而非编译后的目标文件。

@orzfly 话说，风雨雷电的英文都要抱怨，我只能“呵呵”了，所以不要太计较，绝逼不同世界的人

@jjx 请描述一下您使用pg的应用场景，让我们瞻仰参考吧！

虽然没怎么穿过（只大前年澳门买过一双NIKE网球鞋）——个人感觉虽然品牌溢价较多，但品质还是挺好的！

@em70 just do it!
哈哈，我也是各种借口，装备齐了都跑不起来。但自从用了朋友送的手环，APP定目标、Review进度，跑步才真的积极起来！

@Lucups 同意，没有银弹，只有适合。认清楚各种技术的优缺点，分析要实现的系统场景，裁裁剪剪，剪剪裁裁，终成大家！^_^

恭喜恭喜，白頭偕老，早生貴子！
心態好，才幸福，別人的看法不重要！

@hepin1989 有现货吗？要抢吗？还是要等多久才有？已经等不及了！

个人认为，在“开展一天的工作前，review当前工作目标，规划当天工作任务”，效果要远远好过“在一天工作结束时，写详细的工作汇报”，这也是为什么敏捷项目管理开的是晨会，而不是晚会！ 前者基于目标激励，重视信任；后者并非不需要，但简单回顾就够了，第二天晨会再做个简单汇报！

一分为二的看：
1、企业应用强调数据强一致性，性能因为规模的关系，不是主要考虑因素，建议用外键；
2、互联网应用则通常相反，强调性能而相对不着重数据强一致性（只是相对），不用外键对数据操作有性能提升助力，搜索问题则通常采用第三方搜索引擎系统效率更高。

场景不同，着重点不同，采取的策略不同！

又要记笔记，又要有提醒，又有TODO List，我就用了网易的“有道云笔记”，全平台都有，功能也算齐全了，也有Open API，在国内同步速度也很快，在香港用也不错！——符合我的理念：不需要炫，一定程度的大而全保证够用就行，实在不想搞太多App！