[Ffmpeg-devel] Re: Advocating periodic releases

[Panagiotis Issaris]

Hi,

On Fri, Oct 06, 2006 at 05:54:35PM +0200, Diego Biurrun wrote:
> On Fri, Oct 06, 2006 at 05:04:59PM +0200, Oded Shimon wrote:
> > 
> > BTW, I'm really pleased with svn. The history past the current revision is 
> > useless in 99% of normal cases, and I've seen it handle just about 
> > anything I threw at it perfectly. The only thing it doesn't support easily 
> > is the moving of files/directories across repositories, an action which 
> > can't even be easily defined anyway and doesn't really make sense. (If you 
> > disagree, try to think what is the best way for this to be done, and 
> > you'll find that everyone has a different opinion on this...)
> 
> I agree completely.  So far Subversion has served us very well.  This
> seems to get overlooked when the discussion comes to its *one* real
> shortcoming, which is cross-repository commits/moves (or whatever you
> wish to call them).
IMHO once you try a distributed vcs such as GIT (or probably Bazaar and
Bitkeeper), you will not want to go back to systems such as CVS/SVN.

Out of curiosity, if you work on something for FFmpeg, and it is not small
enough to do it in lets say a day/week, how do you manage the codechanges?

I used to do this in a separate repository on my harddrive in which I could
commit as much as I wanted without polluting the upstream repository.

This is what attracted me most to GIT. I could not find a solution. The only
"solutions" I was aware of was either:
1. Storing lots of patches on my harddrive with incremental changes
2. Creating a branch on the upstream repository, but I truly dislike this at
this means everyone can see what stupid mistakes I often make :)
3. Or as mentioned above, using a separate repository and trying to keep them in
sync

I dislike all of the abovementioned methods. Which one do you like and are you
using? Any other way to keep revisions of the big changes you code?

> This issue is being addressed in any case.  I will start working on
> merging the MPlayer and FFmpeg repositories as soon as I find the time
> to do it.  The issue of moving things from one place to another will be
> solved then.
> 
> Also, Subversion 1.4 introduces svnsync, a tool which seems to do just
> what we need.  I haven't had the time to investigate so far, though, so
> I'm not making any promises.
I know about SVK which does the distributed branches on top of Subversion, and
thus must have a way to synchronize between SVN repositories (or maybe they have
some extra data in the repository to make this possible/easier).

With friendly regards,
Takis